Mercurial vs Git

[Felipe Contreras]

On Fri, Jan 21, 2011 at 4:31 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> On 01/20/2011 05:35 AM, Felipe Contreras wrote:
>> Why? How exactly would a floating reference affect your project negatively?
>
> It doesn't affect the project negatively, but it makes a specific scenario I've
> run into before inconvenient for me.
>
> Regardless of how git, hg, mtn, or any other random SCM handles branches, one
> simple fact does not change.  I did *not* work on "master" or "default" or
> whatever branch name when I was working on, say, a yahoo17 branch.  Yes, the net
> effect after a merge is that the *sum* of the branch is on "default", but the
> individual revisions were *not* when they were created.
>
> This is an important distinction to me, because now I can prove to
> $random_annoying_user that "bug X never existed on default because I both
> introduced and fixed it on yahoo17 before it was merged."  If I have to track
> down the commit message of the merge, then walk the graph backward and guess
> what branch revisions ABC and XYZ are on based solely on the appearance of the
> graph, this becomes more of a pain than I'm willing to tolerate.  Even if the
> tool can figure this out for me, I still consider it a deficiency in the design.

There's no "appearance", the graph is the graph, in mtn, mercurial, or
git. And this graph has all the information you need. You have the
point where it was introduced, the point where it was fixed, and the
point when the branch was merged. Git has powerful commands that let's
you find out exactly what you need.

So, the mercurial model is better for you based on a personal feeling,
there's nothing fundamentally wrong that prevents you from doing
something, or that causes something bad.

> Now I'm sure you'll make some argument about "it's your branch; you'll have the
> ref to the head of the branch if you didn't delete it", but that argument
> completely falls apart if I'm proving this for a branch I never worked on and
> never explicitly pulled that ended up on default/master/whatever.  It also falls
> apart if I work from three different working copies on three different machines
> without pushing/pulling changes among them, which I've done on more than one
> occasion--I could be on a machine that doesn't have this all-important floating ref.

No. Who cares whether or not you still have that pointer? You know
which commit introduced it, and you know which commit fixed it, and
you can get the branch merge point of both easily with git. That's all
you need.

> The bottom line is that in my opinion the git model of allowing the removal of
> the branch ref and thus "collapsing" the "branch" into whatever it was merged
> into leads to an inaccurate view of the history that I'm not happy about.  Yes,
> it's obvious from this statement that I don't follow the development model git
> users do.  It's pointless debating this any further (and in fact, further
> messages on this topic *will* be ignored), because you're not going to convince
> me that I'm wrong anymore than I'm going to be able to convince you that you're
> wrong.  I have far more important things to spend my time and energy on.

A branch is a separate line of development. The base of the branch is
the point where two commits have the same parent, and the branch can
be merged to other branches. This "merge" as the English language
defines it means to "absorb", "join", "combine", "become one",
"immerse"; it doesn't matter how you look at it, merging 'foo' into
'master' means that 'foo' is now part of master. The Git model follows
the mental model of "branch".

What you want to define as a branch is actually not. What you want is
something that says "this was here". That's not a branch, that
something different, a "per-commit tag" perhaps, or a "commit label",
or a "branch stamp". While this might be useful in certain limited
scenarios, in the vast majority of situations, it's not. And whatever
you can achieve with these 'stamps', exactly the same can be achieved
without them, with a little bit of more work, which fortunately
doesn't have to be done very often.

Anyway, this is not me convincing you, and you convincing me, this is
presenting arguments to a community which is trying to decide which
DSCM to use. This decision obviously has many implications, and you
can't just switch to another one next week if you realize you made a
bad decision. Therefore the need to consider the decision carefully,
and IMO something that would probably affect years of development is
worth spending a bit of time discussing. So sad that you don't think
so.

>> And that demonstrates one of the many design inconsistencies about this model.
>>
>>  1) commits can be part of no branch, even though they are parents of
>> a commit in the main branch
> <snip>
>> The only thing that prevents those inconsistencies is the front-end
>> app (does it?). With the git model, those things are impossible.
>
> If you want it to be impossible in monotone, you can force it to be impossible
> by leveraging the lua extensibility in .monotonerc.  Simply walk the graph and
> manually "collapse" it into the target branch by issuing branch certs that force
> those revisions onto the appropriate branch.  The lack of a branch certificate
> is not an inconsistency--it's simply saying "this revision came from outside our
> normal world view."  That said, it was meant purely as an example of similarity,
> not a point of discussion or debate.

Personally, that doesn't make sense to me. Every commit came from
somewhere, and every commit that shows in the log of a branch, is part
of that branch.

>> And you would see from which branch the commits came from:
>> Merge branch 'rlaager-foo'
>> https://github.com/ecoffey/pidgin-illustration/commit/6fc76c5bc9ac0929f7fd1e2e2d2fcb2840d394e1
>
> You will see this in monotone too, even without the branch certs, because of the
> changelog cert:
> http://developer.pidgin.im/viewmtn/revision/info/ebb9c5ce48a0ce5b73b9daf7a31c8178bf36fff3

That's irrelevant. What is relevant is that the branch name is not
lost in Git. That is the context of the comment.

>> Sure, I haven't plotted the votes closely, but from what I recall most
>> of the votes where git/hg (slightly favoring one or the other), or
>> don't care. I don't recall anyone saying definitely no to git.
>
> Currently the votes give hg a 4 or 5 vote lead over git (I'd need to go back and
> recount to be sure, but hg is definitely leading).  I don't expect any further
> votes to be cast at this point.
>
> I now consider this topic closed.

Advantages of Git:
 1) more popular
 2) more powerful handling of branches (distributed)
 3) useful tools for pidgin migration (graft points)
 4) more efficient
 5) less space (108M the whole pidgin repo)

Advantages of hg:
 1) Adium/InstantBird use it (not that big of an advantage if hg
clones are offered)
 2) John likes the branch model

Also, the mtn->git conversion takes 30m, while mtn->hg takes about 30h.

So John is out. Hopefully other people would agree that up to this
point, a careful evaluation of the alternatives hasn't been done yet
(nobody has even put a list of pros and cons), and it is desirable to
do so before committing on such big change.

Cheers.

-- 
Felipe Contreras