Jakub Narebski wrote: >First, hydras or n-head was invented to avoid capping and recapping, and >just advance it as a normal head (and to remember what are >subprojects/patch dependency chains/whatever to choose). > >Second, we could generalize those extra commit references in commit >structure (be they "bind", "prior" or "previous", or "depends-on") and have > > Note that these are all quite different types of references. "Bind" implies an unmerged tree to be woven in on checkout, "prior and "previous" a historical relationship, and "depends-on" the previous commit that the change that this commit supplies was based on. So, I think "parent" already means "depends-on" closely enough. >commit/merge pluggable helper manage them. And merge strategy may make use >of them. > >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. Sam. - : 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