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