On 5/1/12 04:14 , Ted Ts'o wrote:
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.
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.
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html