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

branches"

Say you've got a sequence of changes like this:

1. add foo.c
2. add bar.c
3. modify foo.c
4. modify bar.c

The darcs-like operation of this would be to have two sequences of ordered patches that combine to a final result. ie:

  1 -> 3
  2 -> 4

Unless you jump through hoops, git will represent it as:

  1 -> 2 -> 3 -> 4.

However, you *could* represent it as:

  1 -> 3  \
           >- head
  2 -> 4  /

Where "head" is a merge commit that just combines the trees of 3 and 4.

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.

If the plumbing or a porcelain could be smart enough to automatically create hydra when patches are not dependent, then many of the benefits of patch calculus might come for free, without having to create these complicated sounding entities manually.

Of course this doesn't give you the symbolic labelling of patches that can allow darcs to detect already applied, but "mutated" patches, but that might not matter in practice.

Sam.