* Resetting paths
@ 2006-02-10 4:40 Junio C Hamano
2006-02-10 11:44 ` Andreas Ericsson
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2006-02-10 4:40 UTC (permalink / raw)
To: git
While working on "assume unchanged" git series, I found one
thing missing from the current set of tools.
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.
"git reset --mixed" is a heavy-handed tool for that. It reads
the entier index from the HEAD commit without touching the
working tree, so I would need to add the modified paths back
with "git update-index".
The low-level voodoo to do so for this particular case is this
single liner:
git ls-tree HEAD ls-files.c | git update-index --index-info
Have people found themselves in similar need like this? This
could take different forms.
* 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.
BTW, this shows how "index centric" git is. With other SCM that
has only the last commit and the working tree files, you do not
have to worry any of these things, so it might appear that index
is just a nuisance. But if you do not have any "registry of
paths to be committed", you cannot do a partial commit like what
I did above ("commit changes to all files other than
ls-files.c") without listing all the paths to be committed, or
fall back on CVS style "one path at a time", breaking an atomic
commit, so there is a drawback for not having an index as well.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Resetting paths
2006-02-10 4:40 Resetting paths Junio C Hamano
@ 2006-02-10 11:44 ` Andreas Ericsson
2006-02-11 5:18 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Ericsson @ 2006-02-10 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Resetting paths
2006-02-10 11:44 ` Andreas Ericsson
@ 2006-02-11 5:18 ` Junio C Hamano
0 siblings, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2006-02-11 5:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
Andreas Ericsson <ae@op5.se> writes:
> How about "git update-index --undo path...", possibly with "git reset
> path..." as a shorthand.
While "git reset path..." may make sense, "update-index --undo"
does not make any sense from the core point of view. That
command is about interaction between index and working tree file
and does not know anything about "the last commit", "the current
head commit", nor tree objects in general, so it does not know
where to get the undo information from.
I'll find time to code a prototype for "git reset path..." up
unless somebody beats me to it.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-02-11 5:18 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-10 4:40 Resetting paths Junio C Hamano
2006-02-10 11:44 ` Andreas Ericsson
2006-02-11 5:18 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).