Re: [RFC] Second parent for reverts

["Shawn O. Pearce" <spearce@spearce.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 9 May 2007, Daniel Barkalow wrote:
> 
> > 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.
> 
> I am not so sure. In a sense, you are correct. But everybody who does "git 
> log --no-merges" would no longer see reverts. Which is somewhat incorrect.

Right.

I've actually done what Daniel just talked about doing in one of my
"production" repositories.  I did it by hand as a developer had
created a bad merge and accidentially reverted 800 files during
that merge.  80 or so commits later along a public non-rewinding
branch coworkers realized things weren't right, and asked me
to fix the mess.  As I wanted to save the blame data when I
reverted-the-revert I did what Daniel suggests.

But since the revert-the-revert wasn't really an interesting point
in history, and neither was the bad merge, I don't really care that
neither shows up with --no-merges.  The original bad merge was a
simple honest mistake made by a developer who was new to Git, and
was only caused because merge-recursive wasn't installed properly
on that system.


As Dscho says, most reverts are interesting points in time.  *Why*
a particular revert was done is important.

And so I have to disagree quite a bit with Daniel's idea, for exactly
that reason.  If I'm looking at a block of code in a file I want to
know why its there.  If blame tells me its a revert of something,
that tells me we tried another path and it didn't work out.  I might
be sitting here looking at this line because I'm thinking of redoing
whatever it was that wasn't good!

So that revert commit message better say why that thing didn't
work out.

If I really do care about the source of that line, I can always
re-run blame on the parent of the reverted commit (hence why ^
is so nice as a suffix on a commit-ish!) and examine the line again.

Hmm.  I should teach git-gui to parse out the revert message and
let you click into its parent.  Simple enough.  Maybe it will be
in 0.7.0.  Maybe it won't be.  ;-)

-- 
Shawn.