Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why a small team chose Mercurial.

ninthdivision.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Why a small team chose Mercurial.

#11

Post by randallsquared »

Rusky wrote: post #6
dlsspy wrote: post #4

This misconception always bothers me: "In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do." Yes, you certainly can change commits in hg. The tools to do it in git are a bit more refined, but there's no fundamental…

The difference is not fundamental, no. It is a difference in philosophy and interface that discourages modifying history. The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests? Why would you want to eliminate a state where you made something that worked? I don't see the appeal in modifying history. If you just need to save some partially working state, etc. you can use…

I haven't used mercurial in anger, and mostly use subversion instead (because that's what my workplace uses at the moment), but:

1) sometimes you commit by accident. This happens to me a few times a year, from hitting the up arrow the wrong number of times and pressing enter.

2) sometimes you say something in a commit message that turns out not to be true, or is just a typo, and especially if you're using commit messages to tie commits to tickets in your bug tracker, this can make code show up on the wrong ticket, or not at all, which is quite confusing for a later maintainer.

Re: Why a small team chose Mercurial.

#12

Post by dlsspy »

Rusky wrote: post #6
dlsspy wrote: post #4

This misconception always bothers me: "In Mercurial you can’t change previous committed code. In git you can change the past commits in the repo. I am sure there are cases where the linux kernel needs to do this (I can’t think of any), but this is some we don’t even want to have the option to do." Yes, you certainly can change commits in hg. The tools to do it in git are a bit more refined, but there's no fundamental…

The difference is not fundamental, no. It is a difference in philosophy and interface that discourages modifying history. The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests? Why would you want to eliminate a state where you made something that worked? I don't see the appeal in modifying history. If you just need to save some partially working state, etc. you can use…

> The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests?

Because:

a) It's not a stable branch. It's my dev branch on my local box that nobody else can see.

b) I feel like it and there's no penalty. I can go back if something is wrong.

c) The next thing I'm going to do is risky. I should save where I am just in case I'm wrong.

> Why would you want to eliminate a state where you made something that worked?

Because it may not be meaningful and it may not work. In the above case, what value do you gain from the three revisions of that change that were incorrect? When it hit code review, there were problems with it. We fixed them. Why would you publish code that is known to be incorrect (since we figured that out during code review)?

> I don't see the appeal in modifying history.

I don't see the appeal in a history full of "Oops, I forgot to add this file to the last commit," and "build fix" and "The author wrote this on Solaris, but I need a small change in the Makefile for Linux."

If there's one logical change, having several commits where you just didn't get it right only adds confusion.

> If you just need to save some partially working state, etc. you can use patch queues- They make much more sense here.

Are you saying that because that's the tool you were offered or because you actually believe it's the best way to do things?

I used mercurial very extensively before I started using git (which I have also used very extensively). Most of my time was spent in mq capturing state of work in progress. That really sucked.

Now, I just commit whenever I feel like it, and then before I publish code, I update the commit messages, squash distinct changes that represent a single logical change that shouldn't be broken up, break up commits that represent more than one logical change that shouldn't be lumped together and just generally tidy things up so the reviewers and future developers tracking back bugs can make sense of things.

Then I test it: http://dustin.github.com/2010/03/28/git-test-sequence.html

Re: Why a small team chose Mercurial.

#13

Post by 100k »

randallsquared wrote: post #11
Rusky wrote: post #6

Earlier quoted context omitted.

The difference is not fundamental, no. It is a difference in philosophy and interface that discourages modifying history. The question is: Why would you commit (to a stable branch) when your code doesn't build or pass tests? Why would you want to eliminate a state where you made something that worked? I don't see the appeal in modifying history. If you just need to save some partially working state, etc. you can use…

I haven't used mercurial in anger, and mostly use subversion instead (because that's what my workplace uses at the moment), but: 1) sometimes you commit by accident. This happens to me a few times a year, from hitting the up arrow the wrong number of times and pressing enter. 2) sometimes you say something in a commit message that turns out not to be true, or is just a typo, and especially if you're using commit mess…

It is trivial in Mercurial to back out the last commit: hg rollback

I use it all the time to fix typos, add a file I forgot to add, or whatever. Once you push, it is more difficult, but I try not to push my code until it works. I also commit only tested chunks of code, so that is the "unit of work" I aim for.

The equivalent in git is something stupid, I have to look it up every time: git reset --soft HEAD^

That's intuitive!

Re: Why a small team chose Mercurial.

#14

Post by graywh »

100k wrote: post #13
randallsquared wrote: post #11

Earlier quoted context omitted.

I haven't used mercurial in anger, and mostly use subversion instead (because that's what my workplace uses at the moment), but: 1) sometimes you commit by accident. This happens to me a few times a year, from hitting the up arrow the wrong number of times and pressing enter. 2) sometimes you say something in a commit message that turns out not to be true, or is just a typo, and especially if you're using commit mess…

It is trivial in Mercurial to back out the last commit: hg rollback I use it all the time to fix typos, add a file I forgot to add, or whatever. Once you push, it is more difficult, but I try not to push my code until it works. I also commit only tested chunks of code, so that is the "unit of work" I aim for. The equivalent in git is something stupid, I have to look it up every time: git reset --soft HEAD^ That's int…

git commit --amend

Re: Why a small team chose Mercurial.

#15

Post by randallsquared »

100k wrote: post #13
randallsquared wrote: post #11

Earlier quoted context omitted.

I haven't used mercurial in anger, and mostly use subversion instead (because that's what my workplace uses at the moment), but: 1) sometimes you commit by accident. This happens to me a few times a year, from hitting the up arrow the wrong number of times and pressing enter. 2) sometimes you say something in a commit message that turns out not to be true, or is just a typo, and especially if you're using commit mess…

It is trivial in Mercurial to back out the last commit: hg rollback I use it all the time to fix typos, add a file I forgot to add, or whatever. Once you push, it is more difficult, but I try not to push my code until it works. I also commit only tested chunks of code, so that is the "unit of work" I aim for. The equivalent in git is something stupid, I have to look it up every time: git reset --soft HEAD^ That's int…

It sounds as though the equivalent mistake would be an accidental push. Good to know that git and mercurial allow you to fix things, in any case.

Re: Why a small team chose Mercurial.

#16

Post by jackowayed »

100k wrote: post #13
randallsquared wrote: post #11

Earlier quoted context omitted.

I haven't used mercurial in anger, and mostly use subversion instead (because that's what my workplace uses at the moment), but: 1) sometimes you commit by accident. This happens to me a few times a year, from hitting the up arrow the wrong number of times and pressing enter. 2) sometimes you say something in a commit message that turns out not to be true, or is just a typo, and especially if you're using commit mess…

It is trivial in Mercurial to back out the last commit: hg rollback I use it all the time to fix typos, add a file I forgot to add, or whatever. Once you push, it is more difficult, but I try not to push my code until it works. I also commit only tested chunks of code, so that is the "unit of work" I aim for. The equivalent in git is something stupid, I have to look it up every time: git reset --soft HEAD^ That's int…

git reset HEAD^ (soft is the default option) is actually pretty intuitive once you're used to git. You're reseting the index to the state it was one commit ago (which is what HEAD^ means. That comes up a lot.)

And if you really forget it often, add this to your ~/.gitconfig:

    [alias]
      rollback = reset HEAD^
Now you can run `git rollback`

Re: Why a small team chose Mercurial.

#17

Post by Xurinos »

randallsquared wrote: post #15
100k wrote: post #13

Earlier quoted context omitted.

It is trivial in Mercurial to back out the last commit: hg rollback I use it all the time to fix typos, add a file I forgot to add, or whatever. Once you push, it is more difficult, but I try not to push my code until it works. I also commit only tested chunks of code, so that is the "unit of work" I aim for. The equivalent in git is something stupid, I have to look it up every time: git reset --soft HEAD^ That's int…

It sounds as though the equivalent mistake would be an accidental push. Good to know that git and mercurial allow you to fix things, in any case.

git push is reversible, too: http://news.ycombinator.com/item?id=2079967 (and note my correction below that simplifies things)

Re: Why a small team chose Mercurial.

#18

Post by Xurinos »

gecko wrote: post #8
indspenceable wrote: post #5

Pretty good; liked that they didn't just say "HG GOOD, GIT BAD". I'm confused about the git learning curve though; I started using git on my own this summer, and I was able to immediately pick up the commands I needed to get by literally the day I started. I'll admit I don't have to host repositories, like they would in for their company; but for simply using git as a developer it was very painless.

Having taught people both systems, I will assert, based on my personal experience, that while some developers can certainly pick up Git relatively painlessly, picking up Mercurial objectively requires less time, and leaves users less likely to get into a state that they are unsure how to exit. This is purely based on my own personal experience, and I have not scientifically codified the learning time in double-blind…

Having introduced git to a few groups (and some hg), I found that the main thing that makes hg easier to learn is that hg mimics some of the same names of commands as cvs/svn. However, once they understand what is going on in git, the aha moments start to show up, and the really complicated stuff becomes easy.

Re: Why a small team chose Mercurial.

#19

Post by foljs »

jorgem wrote: post #7
atrain34 wrote: post #3

Earlier quoted context omitted.

yes, please read the linked blog post. they used both hg and git quite a bit but found hg easier to host, use and move over from subversion (convert repos but also command line). so yes, cheerleader piece you are right on that. not much cheerleading for hg these days.

>> not much cheerleading for hg these days. Joel Spolsky seems to like it: http://hginit.com/

HG: liked by the guy that gave us Visual Basic for applications, some nice essays, tons of tedious advice on how to hire the top programmers, a ho-hum bug tracking system and an abomination of a meta-language for creating web-apps, both created by said "top" programmers.

Re: Why a small team chose Mercurial.

#20

Post by pacemkr »

I've been using Mercurial for a few years and am now turning to git (one week in, so I won't say much about it) for a very specific and fundamental reason: short lived local branches.

Say you have a repository, fix a few bugs on it, and now you want to work on a crazy feature. What you need is a short lived local branch, because you don't know if crazy feature even makes sense. Unfortunately, there is no built in way to do this in hg. [1] Deleting a branch is not a fundamental concept in hg, and so the advice is to create a new local "clone" of the entire repo. [2] Great, now you have to change the config files for your dev environment to point to a new folder just so you can test out crazy feature. Also, by default all your branches get pushed (although hg will complain about creating remote branches).

In practice, all this turned "branching" into an expensive concept in my mind. That's bad, very bad.

I still prefer the hg elegance and ui to git -- even the output of "hg st" vs "git status" tells a great deal about the philosophy behind both. However, I think hg got branching wrong and that is a fundamental flaw that no amount of elegance at the UI level can compensate for.

I remember when I was making my first choice between hg and git and the advice was "they're pretty much the same, pick one." I think that advice is incorrect based on what I've said above.

[1] http://mercurial.selenic.com/wiki/LocalbranchExtension [2] http://mercurial.selenic.com/wiki/PruningDeadBranches

Post reply on HN