Mercurial vs Git

[John Bailey]

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.

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.

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.

> 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.

> 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

> 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.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20110120/476d34d3/attachment.pgp>