Re: n-heads and patch dependency chains

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 5, 2006, 07:59 UTC
Message-ID: <e0vtdl$e3k$1@sea.gmane.org>
In-Reply-To: <4433723E.1080705@vilain.net>

Sam Vilain wrote:

> Jakub Narebski wrote:

Show 13 quoted lines

>>Third, would using *directory* with for a N-HEAD (containing all the
>>subheads, subprojects, chains, branches, fibers, whatever) instead of an
>>ordinary file for HEAD be a good idea? For hydra if we want it to be
>>easily interweaved with ordinary commit I think we would also need the
>>link for bottom, hydra shoulder, hydra tail i.e. common commit being
>>starting point for all the chains, or subprojects (for subprojects it can
>>be empty tree commit).
> 
> This was similar to the original suggestion, of heads that have multiple
> heads, or hydra. I think the basic rejection for this is that nothing is
> then tracking the progression of the merged tree - unless you keep a
> "cherry picked" tree for the combined work. And of course it is a
> backwards incompatible change.

I thought about keeping N-HEAD and HEAD and updating them simultaneously. With extra fields in commit (however they would be named) use them, without extra fields use ordinary branches, creating histories like in your example in first post in the thread.

I.e. when doing [hydra] commit, add commit to ordinary history (recording the time sequence of changes inside branch) advancing HEAD, and add commit to appropriate chain/subhead/fiber in the N-HEAD and "advance N-HEAD". This would make change backwards compatibile.

The problem would be to keep N-HEAD and HEAD to get out of sync, e.g. when somebody updates only HEAD with an older git... well, we can always advance N-HEAD to HEAD using commits from the time they were in sync to the current head state.

-- 
Jakub Narebski
ShadeHawk on #git
Warsaw, Poland