Re: Newbie grief

From: Rich Pixley <rich.pixley@palm.com>
Date: May 1, 2012, 18:03 UTC
Message-ID: <4FA0258D.4000908@palm.com>
In-Reply-To: <20120501111415.GD5769@thunk.org>

On 5/1/12 04:14 , Ted Ts'o wrote:

Show 9 quoted lines

> On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote:
>> Does Hg do this?  That would explain why my (admittedly half-hearted)
>> attempts to learn it have failed -- whatever tutorial I used must have
>> been written with the idea that hydra branches are intuitive and
>> logical and sane, but did not express the concept as clearly and
>> succinctly as you did.
>
> What Hg does is it requires that all terminal commits (commits that do
> not have children) must be named by a branch pointer.

No more so than git does. It's entirely possible to have commits that have no branch pointer pointing to them.

Show 7 quoted lines

> So when you
> pull in some changes from Hg, there may be a non-terminal commit, but
> before the hg pull finishes, it will create a merge commit which
> merges the current branch pointer and the newly pulled in commits, so
> that when you are done, the branch pointer points at the new merge
> commit, and the requirement that there be no non-named terminal
> commits is maintained.

Not so. What happens is that any commit to a non-terminal commit simply succeeds and creates an additional childless commit. If the new commit had a branch pointer, then it continues to have that branch pointer, even if another commit already has that branch pointer. There are just multiple childless commits with that branch pointer.

Any merges are initiated manually. But merging any other childless commits is the default for "hg merge". (And merge commits have two parents).

The only merges that are done automatically are the same ones that git does on a pull. These are sort of degenerate merges in the sense that they exist entirely in the source code repository graph, there are no lexical or file content collisions.

In hg, I can have revision 1 checked out, you can push, (or I can pull), revisions 2, 3, and 4 into my repository, and my next update will merge 2, 3, and 4 into my current working directory, much like with subversion. In git, your push is refused and I can only fetch if I'm also willing to merge at that very moment.

> Git differs in that you can have a child commit which is not pointed
> to by a branch pointer, and which is referred to only by commit-id.

Hg can do this too.

Show 5 quoted lines

> These child commits can disappear on you, when you do a garbage
> collection; but it allows you to have multiple child commits hanging
> off of a single parent commit, and you can do diffs, cherry picks,
> etc.  But they *do* have a unique name --- the commit id, which is a
> SHA1 hash of the contents of the diff.

Same with hg, except that they are persistent and don't disappear on garbage collection.

--rich