Re: Reverting an uncommitted revert

From: Shawn O. Pearce <spearce@spearce.org>
Date: May 20, 2009, 14:17 UTC
Message-ID: <20090520141709.GO30527@spearce.org>
In-Reply-To: <alpine.LFD.2.00.0905200853010.3906@xanadu.home>

Nicolas Pitre <nico@cam.org> wrote:

Show 22 quoted lines

> On Wed, 20 May 2009, Wincent Colaiuta wrote:
> > El 20/5/2009, a las 5:35, Nicolas Pitre escribi?:
> > 
> > > Having a "trash" reflog would solve this unambiguously.  That could also
> > > include your index example above.  However, in the index case, I'd
> > > record a reflog entry only if you're about to discard a previously non
> > > committed entry.  If you do:
> > > 
> > > 	$ git add foo
> > > 	$ git add bar
> > > 	$ git commit
> > > 	$ hack hack hack
> > > 	$ git add foo
> > > 
> > > then in this case there is nothing to be lost hence no additional entry
> > > in the "trash" reflog.
> > 
> > That's true in the example you provide, but it doesn't really handle Jeff's
> > initial example ("git add" twice on the same file), where it is possible to
> > throw away intermediate state (by overwriting).
> 
> Did I disagree with Jeff's original example?

No, but if you don't read closely enough to notice that the first add affects path "foo" and the second add "bar", you might miss what you were trying to say. I almost thought you disagreed with Peff until I read your example a 2nd time. :-)

You did say "uncommitted entry causes reflog append", so in Peff's original example of "git add a; vi a; git add a", we should be creating a reflog entry for that first added state, which is clearly not a disagreement.

FWIW, I think this is a great idea, but lack the time to code it myself, otherwise I probably would start hacking on it right now.

-- 
Shawn.