Re: Reverting an uncommitted revert

From: Junio C Hamano <gitster@pobox.com>
Date: May 20, 2009, 17:59 UTC
Message-ID: <7vab57zmd8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20090520141709.GO30527@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 7 quoted lines

> You did say "uncommitted entry causes reflog append", so in Peff's
> original example of "git add a; vi a; git add a", we should be
> creating a reflog entry for that first added state, which is clearly
> not a disagreement.
>
> FWIW, I think this is a great idea, but lack the time to code it
> myself, otherwise I probably would start hacking on it right now.

The devil's in the details. There are at least four things you would need to design before start hacking.

 (0) Do you want this to apply only to Porcelains, or do you want to use
     this for plumbing operations as well?

 (1) When would you "auto" write-tree?  When you do "git add" or anything
     that adds new contents to the index?  Or immediately before you do
     something destructive like "git reset"?  Or perhaps both?

 (2) Enumerate the operations that falls into the category you decided in
     the above question.  For example, "git apply --index" and "git apply
     --cached" would fall into the same category as "git add".  If you
     cover plumbing, you would also need to cover "git update-index".

 (3) What should happen when you cannot write the index out as a tree?  I
     think it is easier to make mistakes during a conflicted merge
     resolution than during a straight linear development of your own, and
     one of the cases that would benefit most would be that you have
     resolved a path to your satisfaction but then later you screw up
     while resolving some other paths, losing an earlier resolution.