Re: [RFC] Second parent for reverts

> 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!