On Wed, May 20, 2009 at 11:35 AM, Nicolas Pitre <nico@xxxxxxx> wrote:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html