Still hatin' on git: now with added Actual Reasons

I have read a fair amount of documentation on git. I still don't even know what most git commands do. When people recommend a rebase, I pretty much just pretend that my repository isn't going to die. I wince every time I have to revert a file, as "git checkout" is friendly but "git checkout &#60;filename&#62;" is destructive without warning. I once destroyed a number of local files (I don't remember how) that were thankfully still open in emacs.<p>git is awesome, and git is terrible, often for the same reasons. git is a Sharp Knife, which is fantastic if you need one, and horrible if you don't. I personally have basic distributed version control needs and git is far too sharp for my needs. I have managed to not cut anything important off, but I tread carefully around each command, often worrying that I will irrevocably destroy my files.<p>So, +1 for being way better than previous version control systems, but a friendlier modern version control might easily win.

The complaints about git porcelain are totally understandable. The UI is horrendous. However the internals are elegant and actually much simpler than subversion, so if you understand the internals and do a little rote memorization then suddenly you can manipulate your repository expertly, creating better commits and handling unusual needs with ease. It's the difference between being good with a unix shell and running windows configuration wizards to do everything.<p>I don't expect the OA to grok that, however one thing that I hope the author takes to heart is this:<p>With git plumbing it would be fairly straightforward to create a new porcelain VCS combining any balance of elegance, simplicity and power that you desire. With subversion on the other hand, it is almost unimaginable that they would ever be able to correctly track a merge without a hundred bizarre edge cases due to the fact that their repository structure muddles branches and directories.<p>Why hasn't someone who knows git created a better porcelain yet? Probably because once you know git well enough you don't want to give up any of it's native power just to satisfy some noob's anxiety attack.

&#62; So I edit the file, fix the trivial conflict, and git commit filename.<p>This is a bit vague, but I'm guessing you mean you open up the file in your text editor of choice and edit it directly.<p>What I do these days, probably originally prompted by exactly the sort of frustration you describe, is to run "git mergetool", which I happen to have configured to fire up emerge, but you can use any of a number of tools. Once I'm done, git is happy and I can just push. Initially I was a little grumpy about learning how to use emerge when before I just edited the file with all its &#60;&#60;&#60;&#60; and ==== and &#62;&#62;&#62;&#62; directly, but after learning the tool, I wish I'd been doing conflict resolution this way back when I used CVS and SVN. It's really much nicer and less error prone.<p>So, I hope that's a helpful hint. You're absolutely right about a lot of the unhelpful &#38; unintuitive messages and commands.

All the people suggesting various git commands he should be using are completely missing the point.

Don't give up faith my friend. Git and mercurial are not the end of the story.<p>I'm optimistic that, within another few years (give or take a decade), someone will come up with a VCS that's both powerful <i>and</i> usable. :-)<p>Other than that: I enjoyed your article. Very nice walk through some of the problems and hair-pulling that I'm going through regularly, too.<p>Pro-Tip: My life with git got a bit easier since I keep this big bucket of paste-ready shell-snippets near my terminal window. You know, those handy little 14-liners that look like line-noise at a glance, but get you out of "situations" when chanted.

'git commit -a' is not the answer to your merge problem. You should 'git add &#60;file-you-merged&#62;', then commit.

1) "pull --rebase" might help with one of the particular problems mentioned (though obv. not appropriate for all occasions)<p>2) More broadly: yeah, if you expect it to work Just Like Things You Already Know, it just won't work out for you. It really is a totally different workflow, and it either works for you, or it doesn't. Empirically, it works great for many people/organizations (though, absolutely, not without some trade-offs). But truthfully, yeah, if you're a single developer, disinclined to use some of the niceties and very interested in maximizing simplicity/reducing keystrokes... svn really may be a better fit.

&#62; Cheap branching is better than expensive branching, sure, but that’s like saying influenza is better than cancer. I’d rather just not be ill at all, thanks.<p>Please stop posting this know-nothing's uninformed rants.

<i>I think the move back to CVS/Subversion might be the way to go</i><p>From your complaints, it sounds like you'd really like Mercurial. Give it a shot.

Mike, Git seems unintuitive because you don't have a good grasp of what it does behind the scenes. Imagine trying to get to grips with a Unix shell, if you had no concept of files or directories. In such a scenario, even a simple command like "cat" would seem incomprehensible.<p>If you'll indulge me, I'd like to propose a thought experiment.<p>* * Designing a patch database * *<p>Consider you're responsible for administering a busy open source project. You get dozens of patches a day from developers and you find it increasingly difficult to keep track of them. How might you go about managing this influx of patch files?<p>The first thing you might consider is how do you know what each patch is supposed to do? How do you know who to contact about the patch? Or when the patch was sent to you?<p>The solution to this is not too tricky; you just add some metadata to the patch detailing the author, the date, a description of the patch and so forth.<p>The next problem you face is that some patches rely on other patches. For instance, Bob might publicly post a patch for a great new scheduler, but then Carol might post a patch correcting some bugs in Bob's code. Carol's patch cannot be applied without first applying Bob's patch.<p>So you allow each patch to have parents. The parent of Carol's patch would be Bob's patch.<p>You've solved two major problems, but now you face one final one. If you want to talk to other people about these patches, you need a common naming scheme. It's going to be problematic if you label a patch as ABC on your system, but a colleague labels a patch as XYZ. So you either need a central naming database, or some algorithm that can guarantee everyone gives the same label to the same patch.<p>Fortunately, we have such algorithms; they're called one-way hashes. You take the contents of the patch, its metadata and parents, serialize all of that and SHA1 the result.<p>Three perfectly logical solutions, and ones you may even have come up with yourself under similar circumstances.<p>* * Merging patches * *<p>Under this system, how would a merge be performed? Let's say you have two patches, A and B, and you want to combine them somehow. One way is to just apply each in turn to your source, fix any differences that can't be automatically resolved (conflicts), and then produce a new patch C from the combined diff.<p>That works, but now you have to store A, B and C in your patch database, and you don't retain any history. But wait! Your patches can have parents, so what if you created a 'merge' patch, M, with parents A and B?<p><pre><code> A B \ / M </code></pre> This is externally equivalent to what you did to produce C: patches A and B are applied to the source code, and then you apply M to resolve the differences. M will contain both the differences that can be resolved automatically, and any conflicts we have to resolve manually.<p>Having solved your problem, you write the code to your patch database and present the resulting program to your colleague.<p>* * A user tries to merge * *<p>"How do I merge?" he asks.<p>"I've written a tool to help you do that," you say, "Just specify the two patches you want to combine, and the tool will merge them together."<p>"Um, it says I have a merge conflict."<p>"Well, fix the problem, then tell the system to add your file to the 'merge patch' it's making."<p>Your colleague dutifully hacks away, and solves the conflict. "So I've fixed the file," he says, "But when I tell it to 'commit file' it fails."<p>"Remember, this is a patch database," you reply, "We're not dealing with files, we're dealing with patches. You have to add your file changes to your patch, and then commit the patch. You can't commit an individual file."<p>"What? That's not very intuitive," he grumbles, "Hey! I've added the file to the patch, but it tells me the merge isn't complete!"<p>"You need to add all of the files that have differences that were automatically resolved as well."<p>"Why?!"<p>"Because," you explain patiently, "You might not like the way those files have been changed. It needs your approval that the way it's resolved the differences is correct."<p>"Why to I have to re-commit everything my buddy has made?" he complains, "Seriously, I want to just commit <i>one</i> file. What the hell is up with your system?"

Seems to me he should just use Subversion. He has a mental model of how version control works (based on his prior use of CVS) and apparently doesn't wish to invest the time to learn git's model.

Someone needs to introduce this guy to the concept of rebase and then maybe he'll get on board with branching. And <i>then</i> maybe some of his problems with be solved. I used to have these issues until I started branching and rebasing off a core "develop" and "master" branch.

Am I the only one who reads posts like this and wonders why people make merging/pushing/pulling with Git so complicated? It's really not that hard. Sure there are plenty of esoteric and strange things you can do with Git but I have seen devs go from zero knowledge to using the basics in no time. Some never have to go beyond the add, commit, push, pull and merge commands (with their respective switches) and work quite happily. Sure they aren't Git experts by any means but they are able to get their work done and the tool is just as transparent to their workflow as any other SCM tool.

I sort of take issue with this statement:<p><i>“git is bad for me because it makes assumptions about how I work that don’t match how I actually work”</i><p>I think that it's the other way around. git was built with a specific type of workflow in mind. If you take git and try to insert it into your current workflow with a minimal understand of git (or its intended workflow), then isn't it really <i>you</i> that are making assumptions about how the tool works, rather than the tool make assumptions about how you work?<p>{edit}<p><pre><code> - I make a one-line change to a single file. - I commit my change. - I git push, only to be told “! [rejected] master -&#62; master (non-fast forward)”. (This is git’s cuddly way of telling you to do a pull first.) - I git pull, only to be told “CONFLICT (content): Merge conflict in filename. Automatic merge failed; fix conflicts and then commit the result.” </code></pre> This is because you've created your local tree as such:<p><pre><code> A-B-C </code></pre> And the remote tree looks like:<p><pre><code> A-B-D </code></pre> When you run a 'git pull' it's a combination of two operations:<p><pre><code> 1. 'git fetch' or 'git remote update' which updates your local copy of the remote tree. This is stored locally in the branch &#60;origin_name&#62;/&#60;branch_name&#62; (e.g. origin/master). 2. 'git merge &#60;branch_name&#62; &#60;origin_name&#62;/&#60;branch_name&#62;' most of the time this merge is a fast-forward merge which you don't notice at all. It's when your local commit 'C' has conflict with remote commit 'D' that you run into an issue. </code></pre> In the end your tree will look like:<p><pre><code> A-B--D--E \_C_/ </code></pre> Where E is a commit with that resolves the conflict and has two parent commit IDs which point at D and C. In general, you want to just avoid this kind of stuff in the first place by either using rebase or doing the 'git pull' <i>before</i> you commit you changes, <i>then</i> push them out.<p>[ I'm having a hard time picturing how you would have resolved this with SVN. If you have a conflict between a local file and an update that you are pulling down with 'svn up' what happens? (I've not used SVN extensively) ]<p>{edit}<p>&#62; <i>Well, darn. So, OK, no problem, I already fixed the conflict, so now I’ll just git merge again to get it to make its world consistent, right? Nope: “fatal: You have not concluded your merge. (MERGE_HEAD exists)”. Well, duh! I was telling you to merge, you stupid git. You’re the branches-and-merges-are-easy version-control system around here.</i><p>You're telling git to start a new merge, not complete an in-progress merge. Think of 'git merge' as 'create a commit that merges these two things together.' When you run into a conflict 'git merge' tells you, "Sorry I couldn't automatically resolve this for you, but I got you as far as I could go. You'll have to manually resolve these conflicts and create the merge commit." At this point your working directory is in a state of 'middle of a merge.' You just have to resolve the conflicts that were pointed out to you (adding them to the index once they are resolved), and run a 'git commit' to push out the merge commit.

Duh. I've never got the hang of git either, but I figure git is for those people who don't get enough mileage out of Mercurial because they have 42 megatons of source code, or need git rebase, or just want to shock and awe their friends. But no need to hate git for that. No one's forcing you to use it. You don't like vim? Go ahead and use emacs/gedit/eclipse/perl. You don't like git? Use mercurial. Or subversion, if it makes you happier. Merging is <i>always</i> a pain with VCS, more so with DVCSs because they let you conveniently forget a bunch of patches in that repository copy on the USB stick in your back pocket . And these long mumblish version numbers are also going to stay - but they're not so bad when you use a graphical repository browser (hg view/hg_web/git-web/tortoise<i>).<p>And if you just need versioning for a couple .doc files: use Apache's mod_dav_svn and be done with it (i.e., you can mount it as a directory in Nautilus or the Mac finder and it </i>just works<i>). Even though I like all the fancy stuff in Hg, I started using it and never looked back because it's always been painless. (Oh, and you can work </i>directly* on the repository, version history is mostly useless because it reflects weird program behaviour including temporary files, but you'll never get any conflicts unless you mess up <i>really</i> badly).

I get the idea that he wants version control that 'just works'. Unfortunately version control, like most other software, has become complicated.<p>He needs to spend less time typing and more time reading. I don't think git is something you can reason out just by throwing commands at it.

The fact that you need to install either Cygwin or a 100MB collection of Msys files put us off it for our project. We stuck to Mercurial because we thought it would be easier for newbies to get involved, and it seems to be working.<p>Also, unlike Git, Mercurial is coded in Python.. Git is a mesh-mash of half a dozen different languages. I'm guessing long-term, Mercurial will be maintained better (but might be wrong).

The length of the explanations in this thread says something about the usability of git. Not hating, just saying.

I generally agree with the sentiment of this article, though I feel like I need to get better at using git anyway. It's a leaky abstraction and very unintuitive, no doubt, but after using Git regularly I just can't go back to subversion, the workflow in Git is so much nicer (when everything goes as expected, at least...)

I felt the same way about git but I wasn't able to articulate it as well as he did. Go mercurial!

We all need to throw a tantrum sometimes when things don't work the way we like. It's ok. Let it out. We're computer users, we understand.<p>...feel better?<p>Now shut up and learn how to use your tools.