Re: Newbie grief

[Rich Pixley <rich.pixley@palm.com>]

On 5/1/12 09:13 , Sitaram Chamarty wrote:
> On Tue, May 1, 2012 at 4:44 PM, Ted Ts'o<tytso@mit.edu>  wrote:
>> I wouldn't use the verb branch (and certainly not "hydra branch"),
> I coined that phrase for what was described as "[multiple] HEADS of
> the same branch at once in a single repository".
...keeping in mind here that HEAD is a misnomer as HEAD points to the 
currently checked out commit, regardless of where that commit might live 
in the commit graph.  It might be childless, but it might have children.

What I'm talking about is the situation where a branch can have 
multiple, childless commits.  I've switched to calling these "tips" for 
this discussion.
> Sure. What the original poster wants is that all these unnamed commits 
> be magically associated with the branch they were born in, and be 
> propagated via pushes and pulls. As I understand it, he would like a 
> one -> many relationship between branch name and SHA.
Really, what I want is for the push semantic to have a meaning.  I want 
push to work.  I want pull to work even without merging.  I want to be 
able to share a branch between different repositories and different 
users while the source code control system tracks this for me.  And I 
want to create arbitrary network graphs of repositories who all share 
code via push/pull without manual intervention.

These are facilities that we've had in other source code control systems 
for at least a decade.

It seems as though git is tracking all of the info that is needed - 
excepting multiple tips.  The fact that there are converters, including 
dynamic, real time converters, between git repositories and the hg user 
interface suggest that there is, indeed, a near one-to-one mapping 
between mercurial and git.  The only thing that's missing in git is the 
user interface to provide this semantic.  Instead, git simply doesn't do 
what it is asked to do, which seems like a silly user interface choice.

--rich