
The Git Revolution Is Here - draegtun
http://www.drdobbs.com/tools/the-git-revolution-is-here/240009161
======
ojiikun
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.

~~~
i386
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.

~~~
to3m
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.

~~~
lucisferre
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).

~~~
to3m
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.

------
fghh45sdfhr3
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.

~~~
mercurial
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.

------
xgalvez
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.)

------
happypeter
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.

~~~
giulianob
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.

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

------
drudru11
This would be a great story about 3 years ago

------
positr0n
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!

~~~
xgalvez
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>

------
sixothree
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.

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

~~~
thasmin
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.

~~~
jonpaul
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.

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

