Why Git is Better Than X | Hacker News Reader

Why Git is Better Than X

whygitisbetterthanx.com

97 pointsschacon68 comments

I prefer Mercurial (Hg). I'm sure Git is the preferred choice amongst the alpha of alpha geeks, but for small and medium-sized projects, Hg's simple intuitive command structure, and more than adequate speed (2nd only to Git) is a God send.

Git just seems overly complex for all but the most sophisticated workflows. I could be wrong, but that has been my experience.

I would argue (as I do at the site there) that Git is just as easy to learn and use as Hg, in some cases easier (http://jointheconversation.org/2008/11/24/on-mercurial/). The 'Hg is easier' argument tends to be from those who initially tried Git a while ago.

Actually I started using git just for fun and it was on windows. At first I used just graphical interface gittk. It was very easy and clear. I encourage every git newbie to try gittk. After using gittk "index thing" became a lot clearer. So what I'm trying to say is that Git is not some complex beast with dark powers. P.S. And I'm hardly an alpha geek or even power user.

This was my exact argument for Bazaar. After playing with Git 1.6 for a few minutes today all my usual commands work.

It took me literally 3.5 minutes to get Git setup using the OSX install package and fixing my .profile to include the new path. I'm very impressed.

Now if only Github had a trial membership with a Private repo...

I'm in agreement with Github having a free/trial private repo. It's a huge oversight.

GitHub is totally free and unrestricted for public code. This should give you plenty of freedom to try out the service without paying. Also, as a promotion for Cyber Monday, new signups today (12/1) can get a paid plan free for one month.

Because of this, I just signed up to try it. I'm going to be honest though: I wouldn't have without a private repository. I like to version control my homework, and obviously it's against school policy to publicly post solutions to homework. If this works out I'll end up paying for a micro plan, but I never would have even given GitHub an opportunity without a private repo.

Of course, that's just my opinion. :-) You may not even be targeting students anyway.

I thought github does allow private repositories on the free plan? Maybe something changed, but it used to allow a private repository, but you couldn't share it with anyone.

http://unfuddle.com/ has free private repos and they support git

I'm reminded of Carl Worth's effort to port the HG guide to Git. It was mostly a search-replace effort, where the concepts were more or less the same, and the commands were similar.

i prefer hg too.

cheap local branching: there's bookmarks, there's named branches, and there is mq. one of the cool things about mq is that the patch queues can themselves be an hg repo. so if you're using a patch queue like you would the git index, you can 'push' that state somewhere else as way of backup. can one do that with the git-index? (if you rsync your tree, get ready to rsync huge pack files everytime they change .. see below)

everything is local: this is the exact same thing on git and hg. hg incoming means check another repo for incoming changesets. ergo it needs to contact that repo which need not be remote.

git is fast: we have our source tree in hg and git. ~10k files plus binary stuff. no one notices any difference. on windows, hg is faster.

git is small: maybe so. but you have to remember, (and perhaps understand) about git-repack and friends. hg, is like a self-cleaning oven in this regard.

staging area: if one needs such a thing, there are mercurial queues. if you dont, it's not in your way.

distributed: yes. hg is distributed. that's why it has commands like incoming.

any workflow: same thing in both.

github: http://www.bitbucket.org/

easy to learn: git is easier to learn than mercurial?

ok, now here's what i don't like about git:

storage: it's annoying to have to setup git-repacks jobs for each repo, but that's fine. the real killer for us is that it kills our incremental backup strategy. every time you repack you create a new pack file (in our case huge) and you have to back it up again. in mercurial you can back up the files that changed.

bundles: git now has them but they started in mercurial. i'm putting this down because there seems to be this perception that all the cool stuff happens first in git.

index: fine after you're a pro, but we have had accidents. learning curve is a bit strict with git.

documentation: better in hg. much better actually.

git has gone through a lot of interface changes. is cogito still in use? and then they broke renaming at one point. i'm sure these things are fixed, but we've had no such issues in hg thus far.

in the end they both rock, but i prefer hg.

> if one needs such a thing, there are mercurial queues. if you dont, it's not in your way.

Very true. Mercurial's design puts most of its non-core functionality into extensions (which are easy to ignore if you don't need them), and has a clean setup for adding new extensions. How does git handle that? I haven't looked into the git source lately.

And regarding "incoming", the article says that git has a separate command (fetch) for caching server data, i.e. if there are incoming patches, when connections are available. (According to git-fetch(1), fetch looks more like pull without updating/merging locally. Unless I'm misunderstanding things, the comparison to hg's incoming is probably a bit of a stretch.)

The whole site would be more convincing if you included a section on reasons why git is worse than X as well. I don't know git well enough to know these, except for one: handling large binary files that change frequently.

It would make it seem more honest if you admitted that git wasn't the alpha and the omega when it comes to version control. I think it would also show people that you've carefully thought about this and are not just a 'fanboy'.

The counter-arguments are there in the page source as a comment near the end.

From the comment:

  THINGS GIT IS STILL NOT GOOD AT 
  * windows (all)
  * large files (svn)

> I don't know git well enough to know these, except for one: handling large binary files that change frequently.

For the curious among us: what systems handle this better than git?

Subversion is not terrible at this. It stores binary diffs.

Maybe they've improved this in recent versions, but I remember this being excruciatingly slow.

This seems fundamentally different from what VCSs are usually designed for, and another category of tool may handle the problem better. Rsync might be a good start.

Why I don't care:

Because it simply doesn't matter that much IMHO. A startup doesn't succeed or fail based on which RCS it uses, it may fail if it doesn't use any at all, and it may fail if people are wasting a large amount of time doing silly things (Moving directories in cvs).

If you're hacking open source projects however, then I'd say Git is most likely the way to go.

I version control system determines the workflow so it has direct impact of the internals of a company.

For a small startup team, say 5 person max, is the workflow using git much different than using svn say?

The main advantage I can think of is that git makes it much easier to try out crazy and potentially embarrassing ideas. If you want to do this in svn, you create a branch, which exists on the server, which is visible to everyone else (though I guess many won't have it checked out). And when you commit, you need to be online, unless you've got something like svk.

In git, you just create a local branch, try it out, and see if you like the results. If you do, you can have a buddy pull your new branch and see if he likes them, and if everything's good, merge it into master. If you don't, just delete the local branch and nobody's the wiser. Also makes for really quick commits while you're trying things out.

we're 4 people at a startup using it, and I absolutely love it for the reasons nostrademons mentioned.

We used it in a style where 2-3 people teams shared code to develop a feature, a person often worked on different teams at the same time. When a group finished they forwarded they changes to the 'merge master', a weekly shift of lead developers of the company. After a code review the code reached our main repository or landed back for a review. Sometimes weeks of development arrived to the main tree in a safe way with full revision history. This kind of development method was unheard before, the style change improved code quality and reduced conflicts.

My favorite story when we worked with a college thousands of kilometers away till the last minute to demonstrate a key feature to a customer at a trade show, exchanging revisions by emails, delivered on a USB stick. That's a real technology start-up way to handle development. I wrote and debug a lot of code to that company but my biggest impact was to introduce mercurial to the team.

But since all DVCSes can basically implement the same workflows, the git vs. hg/bzr argument still doesn't matter.

It matters when you realize how much more productive you are when you use a better SCM. I'd recommend giving Git a couple weeks and see if you still feel that way.

There are seriously diminishing returns to this, though. Spending lots of time reading about a VCS that might be 2% better (or a language, for that matter) can be counterproductive, or a form of procrastination. They're just a means to an end, after all.

Some people (including myself) find VCSs fascinating, but at the same time, a strong indicator of an excellent VCS is that it largely stays out of your way. Knowing you have a safety net if you need to track some large changes you may revert allows you to take bigger risks, but having a system which is reliable and doesn't interfere with group communication / workflow is at least as important. In the end, it's just a tool. Pick a pretty good one and move on.

"... Because it simply doesn't matter that much IMHO. A startup doesn't succeed or fail based on which RCS it uses, it may fail if it doesn't use any at all ..."

But you are making a statement not using good tools and it might be harder to get good hackers.

I've used svn and git a little and am shopping around for something to use on a current project. I found git harder to use than svn, given that I'm not a power user. I noted that the last item on the page seems to reflect that--git is only easier to learn than perforce, according to the site.

Is that really true? I might just be dumb, but I had a harder time with git. Given that I'm in mostly single-user mode, it seems like I might be more productive with svn simply because I wouldn't have to wrestle with it as much to get going.

Can anyone recommend a "git for people who can understand and operate svn without hurting themselves?" guide? Or is the value of git significantly lessened in single-user mode?

I generally like to try my best to get people to completely forget SVN when learning Git, because I feel that SVN is fundamentally a bad model, BUT - http://git.or.cz/course/svn.html may be what you're looking for. When you want to really learn Git better (and gain hugely in productivity) check out http://gitcasts.com and http://book.git-scm.com for some Git-specific learning materials.

Thanks to all replies for feedback. I think I will try Git again. Any recommendations on a UI tool (or recommend that I don't use one?). I run Ubuntu and have Vista on my work laptop. If there's a good tool for simplifying adds and commits and what not, I'd like to try that.

I think part of my problem might have been that I tried to learn Git using Github, which made a multi-user situation out of a single-user situation and was unnecessarily complex. For my current project, the source is not public so I can't have that problem ;-)

'git gui' is a bit ugly, but it's actually a pretty nice ui in terms of functionality. give that a try, it comes with git. if you want a little primer from a windows perspective, i did a gitcast on installing git on windows and using the 'git gui' here : http://gitcasts.com/posts/git-on-windows

The biggest problem people have with Git is unlearning Subversion. 'git revert' is not 'svn revert,' 'git checkout' is not 'svn checkout,' etc - if you want to learn Git, leave everything you know about Subversion at the door and go in with an open mind.

The Peepcode screencast on git was very good.

The value of git in team mode is so great that you could say it is significantly lessened in single-user mode.

However, I would still invest the time to learn git, and yes it is more complex then svn.

Like 10 fingered typing git is something you don't necessarily need, but it is a multiplier on your productivity.

I know what you mean, but like learning anything else, it takes some practice to get used to it. You've probably seem some of these links before.

http://git.or.cz/course/svn.html

http://cworth.org/hgbook-git/tour/

http://www-cs-students.stanford.edu/~blynn/gitmagic/index.ht...

If you really just want a minimal source control system, Git does the trick well enough. I don't think you need anything more than 'git init' (make a fresh project), 'git commit -a' (commit all new changes except for deleted or renamed files), 'git add' (to add new files), 'git rm' (to remove files), 'git checkout' (for reverting changes), 'git log' (obvious), and 'git diff' (also hopefully obvious). Put a .gitignore file in the root of your project listing globbed filenames for everything you don't want to manage. Run 'git commit' after every sequence of 'git add' or 'git rm' invocations. That's it. You shouldn't need any more documentation than this paragraph.

Branching is a killer feature, as is clean history management, as is the index, and when you find yourself wishing more control over what happens to your source code, wishing for freedom to experiment, all these tools will be there waiting for you.

'git mv' for moving files, and I'm overly dependent upon 'git status' for checking what's changed.

Agreed on both points, although 'git mv' is optional. As long as the old file is 'git rm'ed and the new file is 'git add'ed in the same commit, git detects the rename quite reliably.

mv is just sugar, though, you can easily copy the file using unix "cp" and delete/add to get the same result. Git does not track renames.

Or, just use the Unix mv, and let Git figure out what you did at the next "git add .".

'git diff' (also hopefully obvious)

Except it's not, since it'll output different things depending on whether you have staged anything or not.

This behavior is sometimes useful, but hardly obvious. Many aspects of git are like this, and it's frustrating, speaking as someone who slowly came around to git and now likes it quite a bit and would recommend it, to see its advocates forget or try to talk around just how difficult it is to learn. (1.5 and 1.6 may have improvements, but the claim that git's now roughly as easy to learn as hg or bzr, especially without understanding its internals, is absurd.)

This is precisely why I suggested doing a commit after every sequence of adds and removes.

but that is (one of) the point of the index. that you can build of to a clean changeset to commit. hg mq is easier i think.

If you're coming from svn then Mercurial is much easier to learn than Git.

Also, I don't know what crack they are smoking but Perforce is easier to learn than Git for basic stuff. The biggest place that I've seen perforce get complex is where people try to enforce all sorts of bizarre (read: stupid, useless) polices.

One night 4 months ago, I found myself terrified by the reality that I due to what was happening with our clients, I needed to fork the codebase. And I was on svn. Ouch.

I had postponed this moment as long as possible using the svn-without-branches approach. But that wasnt going to help me going fwd. That night I figured I had no choice but to plunge into git asap. I was not looking forward to it AT ALL; It seemed at best a necessary cost.

Once I decided to, it took me under 3 days to mostly "get" git and be productive. (And I would not say I am the quickest learner.) Now I would never, ever, ever go back, even for tiny projects.

Key resources for me: - gitcasts for the basics - git channel on IRC for odd questions - git internals from peepcode for a more solid understanding

Best of luck!

Git has some learning curve, since you have to discard your notions of Svn, and learn how Git models a repository.

But once you grasp that, it's pretty easy, not to mention pretty powerful. For me, Git had certain features that gave me a "wow", as I learned about and got use to using them:

1) Local branching - branching is fast, and merging is relatively painless. This lets you experiment with things without affecting the main branch. Branches are like 'tabs' on my browser, but for my source control. git checkout -b experimental_branch

2) Staging commits - You can fix little things that might not have to do with your current ticket, but add them to separate commits. You can do even split edits done to the same file to two different commits. git add -i

3) Rebasing branches - You can move the root of the local branch if you want the changes since then. Even better, you can reorder the commits as long as you haven't pushed it to a remote repository yet. The same task allows you to squash your commits together for a cleaner history. git rebase -i

4) Stashing changes - You can stash uncommitted changes, so that you can perform other operations that require no uncommitted changes. This is useful when you're working on something, but can't commit it to your local branch yet, and something needs fixing on production right now. git stash

Basically, a lot of what Git enables me to do is switch between tasks easily.

Basically, a lot of what Git enables me to do is switch between tasks easily.

As a single developer, I love this about git. Being able to instantly create a new local branch to work on something, even if I only have an hour or two to devote to it, then switching branches and continuing on with the next important task is awesome. At least for me, it basically encourages exploration and testing new ideas because it takes no time and I know the "real" code is still safe and accessible instantly.

Another weekly post about why git's better that anything else. It's just the fourth in four weeks.

I wish I could use Git on one of my current projects. But I need to work with non-programmers (on OSX in my case) and any command line stuff (or anything more complicated than checkout/add/update/commit) is totally out of the question.

Still, I'm sure it won't be long...

I also work in an environment with people who should not be going near their command line. Well, its not that they shouldn't but they don't want to be forced to learn commands.

I'm working on a Git GUI that should be fairly beautiful (I'm a former graphic designer), but there aren't really any good GUIs out there right now.

If you do decide to use some sort of VCS, svn has some great GUIs.

like Versions (http://www.versionsapp.com/), Cornerstone (http://www.zennaware.com/cornerstone/) or ZigVersion (http://zigversion.com/).

Versions is nice because it can easily integrate with their hosted subversion stuff called Beanstalk.

For Mercurial, there is TortoiseHg:

http://tortoisehg.sourceforge.net/

Which works very well on Windows, FWIW.

GitX is a very nice GUI for OS X.

http://gitx.frim.nl/

check out GitX

I am more of a bzr and svn user. Both work quite nicely for me. I haven't really used git on a project.

I know git performance is much much better than bzr but as thats not a major concern for small/medium projects, could someone who has used both bzr and git give some pointers on what one would be nicer to use than the other in areas other than performance?

From what I've seen of bzr and git, if you're competent with one, learning the other won't change your life the way a switch from cvs to bzr might. The way git figures out what you've done to a directory tree using sha1 hashes is interesting; incidentally it won't automatically add an empty directory. In bzr, you tell the VCS what you're doing so it can track operations better; git generally doesn't care about anything but the contents of the files in your tree. The staging area and in-place branching in git are pretty cool, but not essential, and I suspect they'll be picked up by bzr and hg in due course.

Mark Shuttleworth wrote a series in his blog about what he cares about in version control, and why he picked bzr for Ubuntu and Launchpad, which is an interesting counterpoint to the git lovefest we've been seeing here.

by the way, as a nice demonstration of some of this git/github greatness, there have been a number of useful changes submitted by users that have been pulled in and deployed now, including the beginnings of a french translation of the site that I've put up at http://fr.whygitisbetterthanx.com

you can see the network activity here : http://github.com/schacon/whygitisbetter/network - all of which has happened since I posted this news item 2 hours ago.

It's a funny coincidence this turns up when I spent about 30 minutes trying and failing to get Git working with Github earlier. I'm not sure if it was the flaky Windows port or not, but it just wasn't happening.

Git seem nice, but as far as I know Github only use ssh. It suck when you are at work or school.

How is supporting only SSH bad? SSH is (or really should be) allowed through all firewalls. git:// support would be much harder to get accepted.

Inaccurate. For example, in the section for "Any Workflow," the author contends that git is better than bzr, hg, svn, and perforce. However, this is completely false. bzr has far better support for the central repository (svn-style workflow) with its linking of repositories and hg and bzr both have excellent support for the models that Git supports. Funny that the site tries to defend against fanboyism while it itself is a poster boy for it.

The "Any Workflow" section is a little confusing. The fine print says "[Other SCMs] can do the simple flows I've described above, but they cannot do them with multiple simultaneous local branches." I don't understand this well enough to be convinced, and it's hardly good form to use examples that don't demonstrate your point.

You make a good point, so I have removed the dscm tags from that one. I added this because I feel that the ability to keep full branches in the same repository that you can push and delete easily gives you far greater flexibility than bzr or hg, which you can only get the exact same functionality by having separate repositories that are clones of each other. However, since that's not what I was demonstrating in that section and it's a bit too complicated to amend easily, I've removed it and focused in that section on the advantages over svn and perforce. perhaps later...

I should point out that hg is perfectly capable of maintaining multiple named branches in the same physical repository. Checkout hg branch. I am not that familiar with bzr but it probably has something similar.

I disagree - I feel that the branch model in Git and its support in the distributed models gives Git an advantage over bzr and hg in overall workflow flexibility, including the centralized model. However, wmf below is correct in that I did not defend that properly, so I have amended that section.

Furthermore, I have been using Git since the pre 1.0 days several years ago - way before most people were using it, so 'fanboyism', a term that I hate, is obviously not why I use it or why I try to teach it. I feel that it is a legitimately better choice for most people than these other tools and this is my attempt to make those points as simply and as straightforward as possible. If you feel I am technically incorrect on anything, please email me and I _will_ fix it.

Reply on news.ycombinator.com