Re: [boost] [git] Mercurial?

Subject: Re: [boost] [git] Mercurial?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-03-22 19:00:48

Daniel James <dnljms_at_[hidden]> writes:

> On 22 March 2012 17:17, Dave Abrahams <dave_at_[hidden]> wrote:
>>
>> on Thu Mar 22 2012, Martin Geisler <mg-AT-aragost.com> wrote:
>>
>>> Julien Nitard <julien.nitard_at_[hidden]> writes:
>>>
>>>>> It seems that everybody has heard of this magic... but nobody has
>>>>> actually seen it, and nobody can remember where they read about it :)
>>>>
>>>> I do, in case somebody is interested. It's in the introduction to
>>>> Mercurial wrote by Joel Spolski.that was posted here not so long ago.
>>>>
>>>> http://hginit.com/00.html paragraph "One more big conceptual difference".
>>>
>>> Oh, yeah, that guide... :)
>>>
>>> I'm afraid Joel didn't really know what he was talking about back
>>> when he wrote that piece.
>>
>> +1
>
> Wrt. git, the 'magic' certainly predates 'hg init'. For example, see
> the second answer at:
>
> http://stackoverflow.com/questions/1897585/how-does-git-handle-merging-code-that-was-moved-to-a-different-file

No, that answer is full of "I think" and "git should" and so on. It's
not factually correct -- he doesn't give any steps that demonstrates
that Git can merge a change to foo.c into bar.c just because *part* of
foo.c was moved into bar.c.

Please don't believe people who give that kind of fuzzy answers.
Especially when it's *trivial* and easy to test! I made these
repositories in less than five minuttes:

  https://bitbucket.org/mg/git-move-edit/changesets
  https://bitbucket.org/mg/hg-move-edit/changesets

Clone them and inspect them. You'll see that there is a small change in
one branch and a moved function in another. Try merging the branches and
you'll get a merge conflict in both Git and Mercurial.

It's of course clear that you could write a merge tool that would look
at the history and try to be smarter. But neither Git nor Mercurial
ships with such a merge tool out of the box.

> I think it dates back to early git development, when people were
> arguing about rename tracking. I think people might have read too much
> into things like:
>
> http://article.gmane.org/gmane.comp.version-control.git/217

I think that post is about inferring file renames after the fact. I'm
fine with that -- it's annoying to get a bad merge with Mercurial
because someone did

  hg remove foo.c
  hg add bar.c

instead of

  hg rename foo.c bar.c

On the other hand, I've heard people complain about the lack of formal
renamed in Git -- they liked how Mercurial lets you be explicit about a
file rename. We've talked about making Mercurial infer renames like Git
so that we catch mistakes like the above.

> Or maybe got confused with the content tracking in 'git blame'. Or
> things just get distorted as they are repeated.

Yes, that's very true. The "track content, not files" mantra has been
repeated again and again by people who don't really understand what it
means and there is now a lot of developers who will swear that Git is
fundamentally different because it "tracks content, not files".

-- 
Martin Geisler
Mercurial links: http://mercurial.ch/