The Power of Git, Part 2

It's funny to see how people discover DSCM (distributed source code management) systems just because some guy in Rails community noticed it.

I was using Darcs (yet another DSCM) for 2 years. And this bugs me, because everybody think that git is the only one that does this.

I did not know Linus Torvalds was involved with Rails!

Maxim, it's not "funny" or bothersome for any reason whatsoever. It's just generally awesome that people are discovering it. Period. Really, just be happy that bloggers like Kurt are promoting distributed source control and move on.

Wow, if Torvalds is involved with Rails, then the scalability problems are going to go soon. Great.

/LOL>

If SVN is the core and everyone is using git around it, for a while it will resemble a cork surrounded by a bunch of swiss army pocket knives.

Heh, that's how rumors are born. I didn't say it was Linus. Linus wrote git long time before it was adopted by Rails-ians. And there were other DSCMs before Linus'.

I'm sure, lots of Rails-ians think that Git was invented by some fellow Rails guy, because he was sick of some "code ghetto".

But the most bad think I think is that Git is advertised to newcomers as _the_only_way_ to do some code management stuff (e.g. starting new project). And newcomers are forced to learn just another "cool" tool that "does some great magick" without even understanding why's and how's.

Maxim:

Are you trying to make a point about something?

1. I have a Darcs repo from several years ago with some web crawler code in it, written in Haskell and Ruby. I don't see how that's relevant to this, except to point out that Darcs isn't as nice as git.

2. If you look at the [link in the post](http://utsl.gen.nz/talks/git-svn/intro.html#sux), code ghetto is defined as:

>The 'Ghetto' development model

>This is where you send new features into the ghetto so that they can 'battle it out'. The last features standing get re-integrated into another branch known as the trailer park to try to find a new life for themselves.

>Note that ghetto is frequently called trunk, and the trailer park something like releng. The 'hood is frequently mis-spelled "head".

It has nothing to do with Rails.

3. In fact, I didn't mention Rails at all in the post.

Git has three problems that I think make it difficult to switch to in corporate dev shops...

1) No windows support (and cygwin doesn't count). This makes it a non-starter in many enterprise settings. Mercurial is the obvious alternative for you if you have windows people on your team.

2) The command set is large and complex. It deviates needlessly from its predecessors cvs and svn. This creates a bigger activation barrier to adopting it in a team setting. Mercurial is much better in this regard.

3) Unfortunately push is not a symmetric version of pull and this is confusing. If you follow the advice avoid push to a "non-bare" repository then you aren't truly a peer-to-peer system as you have to be aware of which repositories are bare and which might have working copies checkout out. This sucks.

I think 1 and 3 are solveable. I think 2 is permanent.

Boy do I wish I was hip enough to give a shit about any of this.
(regarding comments)

Nice blog though

Typical Rubyist tries to claim he was on the bandwagon before it was cool. Grow up. Darcs does not scale darcs cannot handle big files. Darcs has an exponential time merge resolution which just kills it. Haskell makes darcs chew through memory like it was free and large changes can go over 32bit boundaries in memory usage. All in all darcs had a good UI but failed due to implementation problems.

Kurt, Maxim's point was an attempt to say "I was using before you, so nyer!". This is pretty stupid behaviour and as you have said, he was wrong anyway. As someone else pointed out, move on. I second this advice.

I really never read one single blog post "marketing" Git as "the only" game in town. Developers do know not only about Git but of course the Theory of Patches around Darcs. We do know Hg for a long time, and every Ubuntu user probably heard about Bazaar. One reason I see Git getting traction now is its mature git-svn bridge that closes the gap for people like myself or Kurt. Unfortunately I don't see either cvs nor svn going down any time soon. So we now have a very good and useful workaround. That said I think that both darcs and bazaar have some bidirectional bridge with svn. It would be useful if someone could comment on this. Git is damn fast! And consumes very little space. What got most of us sold on Git - myself at least - was Linus' very compelling keynote at Google Talk. Another evangelist is Randall Schwartz, who is a Perl-ist and now into Smalltalk. No single Railer is considered "the" Git evangelist. For some reason we all got it at the same time, dunno why. But the Linux kernel, X11, and I think that even Kde understood it first: Git is hot now. It will eventually get into Windows, the whole complain about having many commands in the path is a n00b thing as it is being solved with a single 'git' command. Also nowadays Git became almost too easy to learn, I migrated all my workflow into Git in a matter of hours - and I still had time to blog about it :-)

Take it easy guys.

Maxim loves Darcs? Okey!
Kurt loves Git? Np!

Come on, don't start a holywar!

> I can finally use branches the way that I've always wanted to.
> I can finally have several features in development at once on
> different branches, because it's so easy to switch and merge
> between them.

You can do this with subversion too.

It sounds like the story you're telling happened in a professional environment (at work?) and if that's the case, what you're doing is *worse* than using subversion.

Firstly, with subversion you can create a branch whenever you want. It's cheap and easy. In the situation you describe you should create a new branch for the feature, ideally using a branch name that identifies the feature. That way you can check in broken code to share with other developers and it doesn't matter, since it's not on the main trunk and won't effect anyone else.

Using subversion like this is *exactly* the same as using git, except that you're keeping the reference copy of everything (when you commit) on the subversion server.

You're probably thinking now, "but then I'm tethered to the server, with git I can go on a cruise and still keep working and creating branches." True, but how often do you do that?

What's more important is that the only records of your work on this feature are on your laptop, and your coworker's laptop. For an open source project that's fine, but not for a professional project.

What happens if your laptop gets stolen/lost/breaks? Your work is gone. What do you say to your boss then when he asks why you weren't using the subversion repo? The repo server is there to be the one-stop location for all the code in the company, and I bet your IT folks have a comprehensive backup plan for it so nothing is ever lost. By not using it you're being unnecessarily cavalier with the code you're being paid to write.

Stick to git for your OS projects.

Stewart,

>You can do this with subversion too.

You cannot do this in subversion!!

Sure you can branch your code till the cows come home but good luck merging it all back in. Good luck managing multiple versions of a product via branches and repeatedly merging branch to truck or trunk to branch. Have fun resolving the same conflicts over and over and over and over.

Subversion does not track merge operations so tracking these manually becomes an exercise in madness.

Sounds like you either like the pain or are too lazy to learn anything other than SVN and are just making up bullshit excuses for your stupidity.

As Linus would say, "You are ugly and stupid!"

Most of the times when I run git gc after git svn clone I get the whole repo is about 40% to 70% percents of fresh Subversion checkout size.

So git is very space efficient.

@stewart, as @mcnaz said, no, you cannot do nearly the same thing using svn.

Svn does the very naive heuristic of diff-ing only 2 revisions. Plain old merge if you will. This is so naive it will create numerous conflicts that should be computationally trivial to solve. And in fact it is, Git can resolve almost everything and even track blobs of code moving between files. So it takes the code's heritage into account. So excluding real Svn-ninjas, no normal developer ever does a branch because we all know the pain of merging things back.

I work as an offshore programmer. So you can imagine what happens if I would depend on a central online repository. The server goes down, I'm out. The link goes down, I'm out. So, yes, having an offline repository is a no-brainer.

But, I'll not go as far as saying that we should replace Svn right now. Not so fast. The best thing to do is set up a Svn repo - that at least is more robust than CVS. The reason being that we already have lots of support tools made for Svn, like continuous integration systems for instance.

So, if you're a team working locally, in the same environment as the repo. No problem. You don't really need branches and can live with broken trunks, so it's ok to keep using Svn locally.

Now, you need to try something experimental in a new branch? No problem: create an offline Git repo in your machine, git-svn fetch what you need, branch, work work work, merge, work, merge, etc. When you're done, git-svn dcommit everything back. Works like a charm and you don't have to fight politics in your corporation.

Now, the lame excuse of 'your notebook can be stolen' is not nearly a good excuse. If you have subversion and you HAVE to work offline for whatever reason, the risks are the same. But your productivity will decays as you will not be able to easily go back into your server to refetch the original files you just managed to screw up. Let alone merge between branches easily.

So, Git is a must for this kind of environment. It made itself useful for me very fast and I will keep working on svn repos - because my company uses them - but my machine shall never have to have an svn working copy again. I'll definitely not miss svn cleanup so soon. :-)

> Sure you can branch your code till the cows come home but
> good luck merging it all back in. Good luck managing multiple
> versions of a product via branches and repeatedly merging
> branch to truck or trunk to branch. Have fun resolving the
> same conflicts over and over and over and over.

The branching support in svn might not be first class, but the solution isn't to chuck out svn and use git and put your codebase at risk from a hardware failure. Branching in clearcase is pretty painless, and there's add-ons for svn (like smartsvn) that do a lot of the legwork and make merging much easier in svn.

We're talking about a trade-off here:

- developer productivity improvements from using a DVCS
- potential risk of code loss from using a DVCS

And to make sure we're on the same page, I'm not talking about "offshore programmers" and such, I'm referring to the 99% of developers who work in a normal business with a normal office and may or may not have a laptop to occasionally work from home.

In this situation there is absolutely a non-zero probability that their workstation hardware may die or their laptop might get lost/stolen. That is a quantifiable risk to the company's assets.

My point is that this risk is an unnecessary trade-off for the company for whatever small benefit there is in using in DVCS. For the record, I work on complex software for oil/gas and ore mining -- multiple dev versions, multiple products and product versions -- and I don't have any issues with svn. We did have some problems, but then we figured out a formal convention for branch names and our branching strategy so that everyone's on the same page and the problems went away.

"The branching support in svn might not be first class, but the solution isn't to chuck out svn and use git and put your codebase at risk from a hardware failure."

Strawman. That's not what anybody's proposing. _Every_ message on this thread has suggested using git to access a svn central server.

Personally, I'm stuck with Windows, so this isn't an option; I use Mercurial instead. Why, you ask? Because my laptop has crashed several times, and with Mercurial backing up my code is a cakewalk (I just "hg push" it to a repo on my USB drive). I've already used this to restore all my work from a crash once (and any number of times to experiment).

"In this situation there is absolutely a non-zero probability that their workstation hardware may die or their laptop might get lost/stolen. That is a quantifiable risk to the company's assets."

And precisely HOW is that a greater risk while using a DVCS? If your laptop (or USB stick) is stolen, you have the source code on it. That's the case no matter what type of VCS you're using.

If you're not in reach of the central server, you can't check in whether or not you're using a central VCS. If you are in reach, you CAN check in, whether or not you're using a central VCS. If you're using a DVCS, you can check into some other place (as I did with my USB drive) to create a redundant backup.

"My point is that this risk is an unnecessary trade-off for the company for whatever small benefit there is in using in DVCS."

*What* risk? What tradeoff?

The benefits of using a DVCS are huge and immediate. You don't even have to figure it out -- they happen almost immediately. (Especially one with a reasonable UI -- Mercurial is great, darcs is great, arch used to suck, I don't know anything about git.) The advantages include instant backups, phenomenal merges, arbitrary team arrangements and rearrangements, checkin security set by YOUR policy rather than the VCS's implementation choices, and many others.

The drawbacks seem to consist of your impression that someone is more likely to steal a laptop with a DVCS on it. (Huh?)

SVN rocks. It's a great central VCS. I wish I had it back when I was forced to use PVCS "because CVS doesn't handle binary files" (my manager said).

DVCSes work with whatever policy you have NOW. Centralized VCSes work with whatever policies their implementors specialize them for and allow you to configure.

Oh, I have a question for the git gurus here.

Background: the svn support in git is something I really, really wish I had on Windows, but until git is supported on windows that's not an option.

My question: one of the things I love about Mercurial is its ability to push a conflicting merge without actually performing any kind of merge (it just leaves the repository with two heads, and the merge has to be resolved). Can git defer merges like that, or does it unalterably act like CVS by performing an "automatic" merge (which often gets things wrong and sometimes corrupts files by inserting conflict markers into them)?

Disclaimer: I'm not trying to slam git -- it lacks that wonderful SVN feature. I'm also not slamming Mercurial (it works out of the box for me, very pleasant). I'm just trying to find if the things that make me happy about Mercurial also apply to git.

O/t, but Kurt, get ready for lots of unsolicited traffic as a Congressional candidate has declared for an open seat in Oregon (OR-5) who has your name, and he has yet to put up a campaign website so you'll probably be getting quite a few hits in the interim (from people like me).

BTW, he's a pretty good guy, a Democrat, so you don't have to worry about some wacko Republican giving you a bad reputation, though you should expect to see some mudslinging sent towards the other Kurt Schrader eventually.

William:

Git does not merge on push. To do that, you have to fetch, merge, then push the result. By default, git will only let you push commits that are descendants of the remote branch tip.

What you can do is push to a new branch on the remote side, and then resolve it later. I believe this is similar to the two heads you were talking about.