Re: n-heads and patch dependency chains

I was re-reading the hydra stuff and realized I've seen the "a cap that bundles independent tracks together" pattern somewhere else in the history of git.

It is very similar to how "bind commit" would have worked.

With hydra, you keep independently mergeable tracks and bundle their tips together:

    ---o--+
    ---o--+--*
    ---o--+

and advancement of each individual track is bundled together by uncapping and recapping:

    ---o--o--+
    ---o--o--+--*
    ---o-----+

So a hydra cap would record:

 - the result "tree" of the (trivial) merge of the bundled tips;
 - the commit object name of the tips.

A "bind commit" proposal was made to support subprojects living in their own subdirectories. The picture to describe the commit ancestry chain would be almost the same as the above picture, except that it did not uncap and recap, but would have built its own ancestry chain.

It had two different kinds of commit relationships: parenthood and directory structure binding. The component subprojects lived in their own subdirectories (so if you are maintaining an embedded Linux along with matching toolchain, you would have linux/ subdirectory that has the kernel hierarchy, gcc/, libc/, ...), and commit objects had "bind commit-sha1 subdirectory-name" lines to express how the components are bundled together. A commit object would have looked like this:

	tree fc9957b0052df6a8248420395bc9febd66194252
        parent 052df6a8248420395bc9febd66194252fc9957b0
        bind f6a8248420395bc9febd66194252fc9957b0052d linux/
        bind 20395bc9febd66194252fc9957b0052df6a82484 gcc/
	author A U Thor <author@example.com> 1144111304 -0700
        ...

The "parent" line is the commit ancestry as usual, and each "bind" line names a commit object of component project and where in the directory hierarchy the tree for that commit object would be checked out. The "tree" line records the result of grafting the subprojects together. So, for example, ls-tree -d fc9957 linux in the above example would have shown the tree object f6a824^{tree}.

The structure forbid you from binding two separate projects at the same directory in order to enforce clean separation of subprojects, but if you allow multiple commits to be bound at the root level, that could be used as a hydra cap.

I've done changes to support this at the core level; I think I still have the code around somewhere (and the net never forgets ;-), so if you are interested you might want to take a look.

The trickest part was to tell rev-list --objects to work sensibly so that an ancestry chain that contains this kind of commits can be fetched and pushed. The code unfortunately was done before recent rev-list renovation so merging it to the current codebase needs some understanding of how rev-list is supposed to work, though.