>From a discussion on #git, the idea was raised of "multi-headed
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.
-
: 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