From: Andreas Ericsson Date: Fri, 10 Feb 2006 11:44:48 GMT Subject: Re: Resetting paths Message-ID: <43EC7CB0.5040804@op5.se> In-Reply-To: <7vlkwjzv0w.fsf@assigned-by-dhcp.cox.net> 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