Re: Reverting an uncommitted revert

From: Ping Yin <pkufranky@gmail.com>
Date: May 20, 2009, 04:58 UTC
Message-ID: <46dff0320905192158k340ece90xd88af53792056b67@mail.gmail.com>
In-Reply-To: <alpine.LFD.2.00.0905192328310.3906@xanadu.home>

On Wed, May 20, 2009 at 11:35 AM, Nicolas Pitre <nico@cam.org> wrote:

Show 32 quoted lines

> On Tue, 19 May 2009, Jeff King wrote:
>
>> On Tue, May 19, 2009 at 11:10:14PM -0400, Nicolas Pitre wrote:
>>
>> > > So here's the idea: What if Git, upon a revert change (or git reset --hard
>> > > HEAD), "committed" the changes to be reverted and then did the revert with a
>> > > 'git reset --hard HEAD^'?  The reverted files would be disconnected from a
>> > > branch, but they would be available in the reflog to retrieve.
>> >
>> > I think there is indeed some value in having a commit of the work
>> > directory dirty state automatically made before this state is discarded,
>>
>> Related to this, I have wondered if it might be useful to have an "index
>> reflog". If I do something like this:
>>
>>   $ git add foo
>>   $ hack hack hack
>>   $ git add foo
>>
>> Then the first added state of "foo" is available in the object database,
>> but it is not connected to the name "foo" in any way, which makes it
>> much harder to find. If we had a reflog pointing to trees representing
>> the index state after each change, then it would be simple (you could
>> look at "INDEX@{1}:foo" or similar).
>>
>> I don't know if the performance is an issue. We are writing an extra
>> tree every time we touch the index, but in many cases you are already
>> writing a blob.
>
> Well... Actually I think having a reflog dedicated to discarded state
> would probably be a better idea. And...
>

Agree. The issues about losing changes due to wrong operation have raised many times in the list, such as

git add . git reset --hard

With reflog for discarded changes,  this can be easily recovered.