Re: Multi-headed branches (hydra? :)) for basic patch calculus

[Jakub Narebski <jnareb@gmail.com>]

Sam Vilain wrote:

> From a discussion on #git, the idea was raised of "multi-headed
> branches"
[...] 
> If somebody adds a commit (5) that changes "foo.c" again, the darcs
> history would change to:
> 
>   1 -> 3 -> 5
>   2 -> 4
> 
> To represent this in git you could just roll back the head merge commit,
> push commit 5 on that branch, then make a new head:
>
>   1 -> 3 -> 5 \
>                >- head
>   2 -> 4 -----/
> 
> However, if there was support for "hydra", or heads that are multiple
> commit IDs (and necessarily, no blobs in corresponding paths in their
> trees that are not identical), then you would not need to destroy and
> recreate this dummy merge head commit to model your patch history in
> this manner.
[...]

I'm not sure if "hydras", i.e. multi-commit 'heads' are what would make
GIT able to use some of Darcs patches calculus ideas. If I understand
correctly in GIT 'head' (and 'tag') not only identifies commit (commits
in hydra[1]) but also tree (in hydra it is result of trivial (?) merge).
Wouldn't it be better to somehow represent rather partial ordering between
commits in history, to have something from Darcs in GIT? Although I'm not
sure about efficiency, and if we should do detect commits dependency -- or
in other words partial ordering of commits/patches -- at commit or at
merge. And if we should remember (or cache) partial ordering/dependency
info...

[1] I've detected some confusion in this terminology. "Hydra" is
multi-headed moster, yet in your ptoposal it is one head that has multiple
bodies... and "octopus" is taken. I guess the terminology should be
switched (octopus <-> hydra).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git