Re: Reverting an uncommitted revert

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > 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.