From: Wincent Colaiuta <win@wincent.com>
Date: Wed, 20 May 2009 09:15:31 GMT
Subject: Re: Reverting an uncommitted revert
Message-ID: <025225A0-FACC-4A29-A747-40201A7FBA19@wincent.com>
In-Reply-To: <alpine.LFD.2.00.0905192328310.3906@xanadu.home>

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).

I personally haven't been bitten by a mistaken use of "git reset" and  
friends for a long time now, but I really like the ideas that have  
been mentioned so far in this thread. This "trash" or "index" or  
"reset" reflog would be a huge step forward in "idiot-proofing" Git.

Cheers,
Wincent