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...
> > and stuff a reference to that commit in the HEAD reflog. I think such a
> > feature would need to be made configurable and active by default.
>
> I'm not sure if putting it in the HEAD reflog is a good idea. The
> reflogs and what goes in them are very user-visible. Do users make the
> assumption that HEAD@{1} will be where they expect (e.g., because they
> just did a reset, they expect HEAD@{1} to be the prevoius commit, but
> with this patch it would actually be HEAD@{2}, with HEAD@{1} as the
> worktree pseudo-commit)?
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.
Nicolas
--
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