The Git Revolution Is Here | Hacker News Reader

The Git Revolution Is Here

drdobbs.com

46 pointsdraegtun41 comments

It is interesting that they mention Perforce releasing a git-compatible frontend/adaptor. I've heard that at least two top-10 code shops (hint: both are in Seattle) built something like this in-house over a year ago since they were unable to switch away from P4 but wanted to placate newer devs that liked git.

The Perl source code use to be on Perforce before moving to Git a few years back. They probably could have done with this adaptor because it took some effort to get 21 years of Perl commit history over to Git! - http://www.perlfoundation.org/perl_5_development_now_on_git

extra ref: Perl5 git repo: http://perl5.git.perl.org/perl.git | Github mirror: https://github.com/mirrors/perl

Many companies I spoke to are stuck with Perforce because its the only version control system that has been proven to scale with thousands of users. Thats not to say Git can't scale but convincing enterprises that Git can scale and showing how they can do it is the next challenge for Git evangelists.

Many enterprises will stick to expensive paid solutions because if anything goes wrong they need to be able to sue someone.

And yet most of these expensive paid solutions have EULAs that strictly tell you that you're not going to get anything if you sue them anyway...

they need to be able to dial support.

FTFY. Vendor apps and commercialized software aren't purchased (to my knowledge) with the intent of being able to point the finger with the buyer's lawyer. The reason large enterprises prefer Perforce/TFS/etc. is (along with their proven capability to scale) that if something goes wrong they can call the vendor for help.

While you might be able to post on a usergroup and hope for a response, you can't call Linus directly. That's a big difference for the people making the decisions from a financial, architectural, and tools-planning level.

You can buy Git support from several different vendors. Were you honestly not aware of this? Try googling for "Git support".

Which isn't quite the same as being able to get support from the company which built the software and who can push out a new release to fix the bug that you've just run into.

(is there a better way to do quotes on HN?)

> Which isn't quite the same as being able to get support from the company which built the software

I'm sure they'll build Git for you if you ask :) Do you think the original authors of Perforce etc. are still with the company? Are you under the impression that their current development team understand the Perforce source code far better than people providing professional Git support understand Git's?

> and who can push out a new release to fix the bug that you've just run into.

That's exactly what Git support can do. Why not?

[edit: to clarify who "they" are]

Christopher Seiwald is still at Perforce. I would have to say: Yes, the current Perforce development team understands the Perforce source code intimately at least as well as the core developers of Git know Git, if not better.

Disclaimer: I work for Perforce

I don't think git can scale, at least not currently, to the extent perforce can. There's two main problems holding it back:

- Storage of database on local drive - the last time I worked with perforce, HEAD alone was 280GB... where would this fit? (there's a presentation about google's use of perforce where they say the metadata alone for their database is >1TB! - so even storing just metadata might not fly)

- As number of people using database increases, chance of needing to store hand-modified binary files (Office, Photoshop, Maya/Max/XSI/etc.) increases, and advantage to storing non-modified binary files (old builds, tools, etc.) increases. (Storing things in shares on people's PCs, or having two systems, or whatever, just ain't great.) Centralized locking is pretty much essential for such files, but, being centralized, it's hard to support with a distributed system...

The former problem could almost certainly be solved. The latter I'm less sure about. Partly for technical reasons, but partly because the idea that binary files shouldn't be version-controlled is, for some people (and I don't know if the git people are of this mind), a point of inviolable principle.

You would be surprised. Git's differential compression is pretty impressive. I worked at an SVN show where HEAD was about 270mb but when I cloned it in Git the bare repo was only 130mb. Git also let's you clone parts of the tree and sections of the history (at least when working with SVN it did).

That's mostly a SVN problem; checkouts are exceptionally large due to that they have a lot of metadata and a second copy of each file for local diffing/etc. which are uncompressed. Perforce doesn't do the same thing.

You may be right. My suspicion would be that a lot of the data is not terribly compressible, and that you'd be looking at over 1TB for the repository of a decent-size project. Add one checkout of head on top; add build products to that. Build products mount up surprisingly quickly, with multiple gigabytes of objects and PDBs being common.

1+TB (and git doesn't support partial checkouts) would make it difficult for people to work off a laptop, or use a SSD. Everybody would need 2 2TB drives on the off chance that they might have to work on more than one project at once. Or you'd have to check less stuff into the git repository.

I know people say disk space is cheap; I just don't think it's quite cheap enough yet to piss away to this degree. It's one thing to have a server with masses of storage, I'm just not convinced you can require every client PC to have the same. I could be wrong.

Shallow clones might be a partial answer to your first point. You can use the --depth X option on the Git command line to only fetch the last X revisions. This means the shallow clone can be much much smaller than the complete clone.

Can the extensive code-review systems often layered on top of Perforce be achieved with git?

As someone who has used both, the workflow features geared towards large organizations and professional-grade code processes have always struck me as a major feature of p4.

http://code.google.com/p/gerrit/

Atlassian Stash was released recently with a code review process built around pull requests (For those that don't know, Stash is a Enterprise Git repository server)

http://blogs.atlassian.com/2012/10/stash-13-enterprise-git-p...

Disclaimer: I work for Atlassian

Having helped several large companies migrate I would agree that this is a top concern, but it can be shown that Git can handle all of the users without any problem. Common tips like: If you are using pure ssh beyond 500 users you want to move away from the stock sshd. When possible setting up git to handle fetches over smart-http can scale git significantly (I would use all available bandwidth to the box before the cpu was anywhere near to pegged). The usual server side backups, routing and distributing load to local offices are all issues that are not too difficult to deal with. Even going through a worse case situation and on purpose corrupting the git database as an exercise is worth doing with new admin's. Inside the enterprise firewall there are a number of tools such as gitolite, github enterprise, gerrit, etc out there that are available to make the users and server admin's happy. Beyond that there are presentations, books, youtube videos, wiki's etc. I found making sure there is one "local export" really helps make things go smoother and and internal chat room / mailing list for Git can't hurt too.

Slowly migrating users by teachings the early adopters with git-p4 also helps to prevent the sudden switch on "Monday" that goes horribly wrong causing everyone to loose a few days.

The real problem has been shops that have 400GB perforce servers and they employed absolutely no rules about where things would live on the server. This would result in Perforce clients that would cherry pick directories from all sorts of random sub directories across the Perforce server to build a product (v.s. say something simpler like projectFoo/, 3rdparty/, and binaryTools/) The worst are the exceptions in the perforce client such as the perforce client would grab the src/ directory, but exclude src/vs/ because a few years ago someone checked in a visual studio install into the src directory and somewhere someone is still using it so they can't remove/move it... Even if they stick with Perforce companies like this really should clean up their repositories, call it simple professionalism.

After a repository is cleaned up (even a basic pass can make a huge deal) then using git on top of perforce or even thinking of migrating is much easier to do.

Using Git inside large companies is completely doable right now. In the past when Git was younger I gave a few presentations in the Boston area (where I live) to companies that were interested in learning more. If your in the area and if you just want to pick my brain on the topic or how it might apply to your situation I am always up for grabbing lunch.

What do you do about storing binary files in git? And is git not actually bothered by having a 400GB repository? I was under the impression that sort of thing was just not its intended use.

At least one big company that was using Perforce to store tons (TB's+) of binary assets that was looking to migrate to Git after talking it over with them I ended up recommended they stick with Perforce. For users that are just looking for a place to store files and not looking to take advantage of features of a distributed revision control system Git isn't the best solution.

A good example is a special effects company where you have a massive amount of assets (PB?) including storing multiple copies of each frame in full resolution raw for the movie. If it you only wanted HEAD local hard drives can't even hold all that data and you only want to work with small parts at a time. For this situation stock Git is absolutely not what you want.

Before anyone tries to sell you that "of course Git scales" you really need to find out more information. Git does have large file support via extra tools that solve it in a handful of different ways, (sidenote one tool: bup is a very very cool from a technical perspective). With large repositories you must also find out are you dealing with a lot of small files or a handful or large files. Windows for example will fall on its face if you try to dump it with a ton of files which git will stat (say just a 4GB git repo) when you run git status while linux can't handle it with no problem. Once you get beyond 4GB in repository size you need to evaluate the problem more closely. Nine times out of ten it has been as simply as splitting the repo into two, one that contains the source and is 1GB and leaving the 399GB of binaries (for 6 platforms, debug and release, etc etc) in a better long term archive storage system be that another git repo using one of the above tools, perforce, or most likely some server that IT manages. An easy way to look at the 400GB repo is today I doubt you are syncing all 400GB to your laptop from perforce (Stock macbook air's max out at only 256GB for example) so how is your perforce client setup? What data does it grab? which data does it leave on the server?

The point about using separate storage is reasonable. Leaving aside the issue of locking binary files, having to potentially use multiple systems or repositories is partly my stumbling block when it comes to any serious replacement to perforce. There are real benefits to having just one system, and having absolutely everything in just one place. One set of revision numbers, one client program. And, most importantly, no need to think about what to do if you have something you want to keep (aside from putting it in an appropriate folder, as you rightly point out). If you want to keep it, it goes in perforce. Doesn't matter what it is, or how much of it there is, perforce will take it. And that's that.

I've seen the annoyances of using multiple depots/databases/repos/etc. with Alien Brain in the past, and that was just one system. Now I'm working on a smaller project that uses both git and SVN, and even though it's a smaller project, it's still annoying today. Being able to have just one system, that can swallow absolutely everything without a fuss (while not being especially annoying to use, like Alien Brain was), is a big advantage.

Well don't put Perforce on such a high horse. Yes it can hold a lot of data, but one common reason brought up from corporate IT guys about why they were looking into Git was that they were having some problems scaling Perforce. From downtime to storage issues, cpu's overloading, etc. The lag from a remote office was annoying, the read-only replication servers had some annoying bugs that forced some users to abandon it, etc. On more than one occasion I have heard horror stories about the lag if you want to sync from 8:30-9:30 in the morning or are trying to sync/commit at 5pm in a large development office. Various perforce commands are very expensive and they all run on the server side so the equivalent of git blame can really tax the server. And if the server ever went down unlike Git you can't keep working. All of the above means you need beefier and more expensive Perforce servers. And don't forget about the licensing costs!

Sure Perforce is nice, but it is hardly perfect. No product is perfect and for every situation you want to evaluate what the real issues that need to be solved and make the tradeoff's necessary.

I've heard of a few cases where teams were able to use git-annex to store large binaries. See http://git-annex.branchable.com

git-p4 isn't really a good tool if your Perforce repo has branches... But you can get it to do the job with enough effort, and it's probably fine as a simple front-end (I never used it as such). My experience with it consisted of migrating LucidDB from its hosted Perforce server over to GitHub last year, which involved the fun process of learning how to graft new parent-child topologies into a git repo.

I like and occasionally use Git, but I started with Mercurial and still prefer it. Can anyone tell me why/how Git allegedly become way better than Mercurial? I seem to have missed that.

I haven't used Mercurial for a while, but on the top of my head:

- lightweight branches (your branch is just a different head, there is nothing permanent about it)

- git rebase -i (rewrite your history)

- git add --patch (add parts of a file to a commit instead of the whole file)

- the philosophy of preparing the commit by putting the files or portions of files you want to commit in the staging area, as opposed to committing everything per default

I know Mercurial has alternatives to most of these functionalities, through various plugins. But I can't say I found them nearly as usable as Git. And that's saying something considering Git's command line interface.

I don't think the article says Git is way better. It says it is way more popular, which is clearly true.

In case people are wondering what the Perforce front-end/interface to Git was, I believe it's their "Perforce Git Fusion" product: http://www.perforce.com/git-fusion

Webinar's next week, and I may sign up to see what this is all about. (Disclaimer: Certified Perforce Admin here, and no, I don't work for Perforce.)

I've been a git super fun for years. But I have to say Hg is much more friendly to newbies. My reason for git's popularity is:

The code is out of the hands of Linux kernel team, so you can believe that git will work well. And the fame of Linus and later github also count.

Github attracted a lot of the Ruby developers. They are extremely vocal on the web which I think is what made Github and Git so popular. I personally prefer Hg over Git as well due to friendlier syntax but Git hit it off a lot better w/ that vocal OSX community.

I don't know many people who use Windows that like Git. The ports were buggy for a long time and the best visual tool, SmartGit, isn't free. Mercurial which has TortoiseHg which is excellent but I hear is painful to get running on OSX (maybe this has changed). Mercurial is fairly popular still though. I think a lot of people use it but not many popular articles get written about it the same way it does about Git.

Yes, ROR people talked a lot, on web, that also counts.

This would be a great story about 3 years ago

What is the git front end to perforce they talk about? All I know about is git-p4 (open source python script, still a little buggy last time I checked) and P4-Sandbox, which is supposed to be DCVS type features implemented in perforce.

A real git front end would be awesome!

Not sure it's a front-end (looks like it's a Perforce front-end to Git), but I believe it's an interface that makes the two work together: http://www.perforce.com/git-fusion

The fact that the project managers and office staff at my workplace are unable to / incapable of using git is a deal-breaker. Git needs serious work in this regard.

Shameless plug: http://gitpilot.com this is part of the problem that we are trying to solve. We would love more feedback.

I'm not sure what gitpilot does. It's difficult to understand what's happening on the video. Two suggestions: 1. Windows client and 2. screenshots next to each of the six items on the page to demonstrate what you're explaining.

Thank you for your feedback. Of all of the market research that I've done so far, it seems that there still isn't a lot of Git developers on Windows. Outside of your own development, are many of your peers using Windows/Git?

Excellent suggestion with the screenshots and the six items.

Maybe I'm missing the point, but I'm using this http://windows.github.com/ and it's pretty good, specifically the shell.

Git/most Git clients weren't designed for project managers or other document users. [shameless plug] Perforce has a new product (http://www.perforce.com/products/commons) that we're working on -- a client that IS designed for those folks/for document-sharing-and-versioning use cases.

So if some developers are using Git, and the idea is to keep all company stuff in a clearly-shareable and accessible spot, Git + Git Fusion + p4 + Commons would do it.

[Disclaimer: I work at Perforce, hence shamelessness of plug]

Reply on news.ycombinator.com