Re: Newbie grief

From: Ted Ts'o <tytso@mit.edu>
Date: May 1, 2012, 11:14 UTC
Message-ID: <20120501111415.GD5769@thunk.org>
In-Reply-To: <CAMK1S_jwVsyKrGoL5uVAiuRrOa8bz79-DAueBmHZE2k=PpcJ2Q@mail.gmail.com>

On Tue, May 01, 2012 at 09:14:24AM +0530, Sitaram Chamarty wrote:

Show 11 quoted lines

> 
> > Multiple heads are the idea that a single commit can "branch" in the
> > repository and that both commits can be HEADS of the same branch at once in
> > a single repository.  This allows a potential collision to exist in the
> > repository and to be pushed and pulled through multiple repositories.  It
> 
> That is bizarre; I have no other word for it.
> 
> I teach git (occasionally), and if this feature existed I would
> totally ignore it in my teaching material because I wouldn't know how
> to defend or explain the need for "hydra branches".

I wouldn't use the verb branch (and certainly not "hydra branch"), because it's confusing to someone who thinks this has something to do with noun "branch". But that's a confusion because of the english, or rather the terminology that was used.

I would put it this way. Every non-merge commit has a parent (we'll ignore merge commits for now). When you look at that commit via "git show <commit-id>", what you see is the diff between its parent and the state of the source tree as described by that commit-id. If you put it this way, it becomes obvious that a particular parent commit can have multiple child commits. (This seems to be what you are calling "hydra branches".)

A branch is a pointer to a commit. When you add a commit to a branch, you are adding a new commit whose parent is pointing to the current branch head, and afterwards, the branch head pointer is changed to point at the new commit.

Show 5 quoted lines

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

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

Does this help?

						- Ted