The discussion about having a header to specify, for a revert commit, what
it reverts made me realize that this header *would* be useful, but that we
don't need a *new* header for it. I think that the right method is to add
the parent of the reverted commit as a second parent for the revert.
If you have:
a -> b -> c -> d
And you want to revert b, the most exact flow would be:
a -> b -> c -> d -> e
\ /
-> a' ---
I.e., you exactly remove the effects of b to generate a commit that has
the same tree as a, and then you merge.
But a' doesn't actually take anything from b, since it's reverting all of
b (unless it's only reverting part of b), and, if b isn't there, it
doesn't need a commit message, either, so it's not different from a. So
the flow should be:
a -> b -> c -> d -> e
\ /
--------------
And this means blame work correctly: lines that b changed will be blamed
on a (or an ancestor), because e will match a there and be different from
d. So I think git-revert should simply add in the reverted patch's parent.
Does this analysis make sense to other people?
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: 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
