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