Re: Resetting paths

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> 
> While I worked on parts of the system that deals with the cached
> lstat() information, I needed a way to debug that, so I hacked
> ls-files -t option to show entries marked as "always matches the
> index" with lowercase tag letters.  This was primarily debugging
> aid hack.
> 
> Then I committed the whole thing with "git commit -a" by
> mistake.  In order to rewind the HEAD to pre-commit state, I can
> say "git reset --soft HEAD^", but after doing that, now I want
> to unupdate the index so that ls-files.c matches the pre-commit
> HEAD.
> 
> 
> Have people found themselves in similar need like this?  This
> could take different forms.
> 

Sometimes, yes.

>  * you did "git update-index" on a wrong path.  This is my
>    example and the above voodoo is a recipe for recovery.
> 
>  * you did "git add" on a wrong path and you want to remove it.
>    This is easier than the above:
> 
> 	git update-index --force-remove path
> 
>  * you did the above recovery from "git add" on a wrong path,
>    and you want to add it again.  The same voodoo would work in
>    this case as well.
> 
> 	git ls-tree HEAD path | git update-index --index-info
> 
> We could add "git reset path..." to reduce typing for the above,
> but I am wondering if it is worth it.
> 

How about "git update-index --undo path...", possibly with "git reset 
path..." as a shorthand. Support for temporary indexes already exist, so 
it should be a simple (and atomic) operation of copying it out with the 
paths mentioned skipped, and then overwriting the current index. I'm not 
sure how well it would perform on very large repositories, but having a 
snappish command to undo a blunder is usually welcome even if it takes 
half a minute or more to run.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231