Comment by mckoss | Hacker News Reader

Comment by mckoss | Hacker News Reader

Parent Full thread

I use both git and hg - and like both of them (though I have more experience with hg). Github is far and away the best hosted distributed version control service, with a constant stream of innovative features for open-source developers over the last 2 years.

Git has had two main drawbacks in my mind. 1) Much of it is implemented as script commands, and I think it still requires you run an emulated shell in Windows to use it (by contrast, Mercurial is a pure python app, and is ultra-portable). 2) Coming from the Linux community, it seems a little heavy weight for small projects. Some command require what seem like extra steps on Git as compared to Hg. For example, Git requires that you do a "git add" before doing a "git commit". Mercurial assumes that you want to add all the changed files in your repo (or you can list the files needed in a commit).

For complex scenarios, Git's system does provide a bit more control in packaging up exactly the set of changes you want in each atomic revision.

Besides these minor historical differences, I think they both are excellent, and are really a matter of personal or team preference.

Git requires that you do a "git add" before doing a "git commit". Mercurial assumes that you want to add all the changed files in your repo (or you can list the files needed in a commit).

This is one of the features of git I most appreciated when I started using it (my first VCS was Mercurial).

I get distracted easily. While I'm rooting through the code base trying to do something, I'll notice something else to fix. And something else. And something else. By the time I've finished whatever I was trying to do in the first place, I've got 5 or 6 different things I've actually done.

In git, it's trivial to split these up - `git add` separate files, or `git add -p` when you only want to stage some of the changes in a file. This leads to cleaner commits.

I've heard people decry this, saying that you should be testing each individual state of your codebase. git being the powerful sonuvabitch it is, you can do that:

* `git stash --keep-index` will store away all of your modifications, other than the ones you're getting ready to commit. Run your tests, commit, `git stash pop`. * Checking out different revisions and running tests isn't a bad option, either, whether you use `git bisect` or do it manually. With the amazing power of `git rebase -i`[0], you can easily fix any little issues without disrupting other commits.

[0]: http://schacon.github.com/history.html

You will change their SHA1 sums, so they'll become different commits. This isn't a problem, though, if you haven't pushed them up to a shared repository.

The differences on commit both have good arguments. hg is going for ease of use and is very much like the non-dvcs's that came before it, like CVS and Subversion where a commit commits all changed files.

git add just adds the file to the index and stages it for commit, this means you can group files logically depending on what has changed, you can even using git add -p have only certain parts of a files modifications be committed and the rest be staged for the next commit. This can be very powerful.

For example, if I did a full refactoring of a class, and fixed a quick bug rather than committing them both at the same time in the patch I can just keep the bug fix and then later commit the re-factored code even if it is in the same file.

Exactly. And if you know that you just want the SVN/HG commit-everything, just add a -a. Pretty intuitive.

Once you get used to having the ability to create arbitrary commits from a huge changeset, you'll find it aggravating when everyone else commits "3 bug fixes to core, swapping out a style sheet, and cleanup in database code" :)

Unfortunately people working with git at work are still doing exactly that. Not sure how to make them stop either, since so far telling them it is wrong hasn't helped ...

erase and rewind

aka push -f and yell at them.

Do they know 'git gui'? Imo the visual view helps to commit several unrelated things separately.

Reply on news.ycombinator.com