Restore a single file in the index back to HEAD

Hello,

I have something like this:

# On branch refs/heads/newmaster
# Updated but not checked in:
# (will commit)
#

#   modified:   oops/file1
#   modified:   good/file2
#   modified:   good/file3
#   modified:   good/file4

i.e. the index has been updated to hold oops/file1

If I then didn't want to commit oops/file1, how do I restore the HEAD oops/file1 back to the index without doing a full reset?

What I'm wishing for is a per file reset...

git-reset --mixed HEAD oops/file1

(I realise that the above is crazy, but I hope it's explaining what I want).

When I do a git checkout -f oops/file1; I get

"git checkout: updating paths is incompatible with switching branches/forcing Did you intend to checkout 'oops/file1' which can not be resolved as commit?"

Andy

Dr Andy Parkins, M Eng (hons), MIEE

On Thursday 2006 October 26 16:42, Alex Riesen wrote:

Thanks for your suggestion.

This returned:

"git checkout: updating paths is incompatible with switching branches/forcing Did you intend to checkout 'oops/file1' which can not be resolved as commit?"

I'm not sure that checkout will do what I want anyway because it would overwrite the working directory copy of oops/file1. I want to keep the changes but reset the index to have oops/file1 from HEAD.

Maybe I need to say a little more about what I'm trying to do:

I converted a subversion repository to git. In that repository I maintained my own set of patches in one branch against an upstream branch; I'm now using git-cherry-pick to pull a subset of those patches onto a new branch against the upstream head. This is all working fine. The problem is that I've come across a patch that should rightly be two patches instead of one.

So, I cherry-pick a patch, which updates the working directory and index, leaving me with...

# On branch refs/heads/newmaster
# Updated but not checked in:
# (will commit)
#

#   modified:   oops/file1 
#   modified:   good/file2
#   modified:   good/file3
#   modified:   good/file4

Instead, what I would like is

# On branch refs/heads/newmaster
# Updated but not checked in:
# (will commit)
#

#   modified:   good/file2
#   modified:   good/file3
#   modified:   good/file4

#
# On branch refs/heads/newmaster
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# modified: oops/file1

I've actually found a way around the problem. I do git-reset HEAD, which restores the index entirely but leaves the working directory. Then I git-update-index the good/* set. However, it led me to wonder what the inverse of git-update-index is.

Andy

Dr Andy Parkins, M Eng (hons), MIEE

git-update-index :-)

You can use something like:

    git ls-tree HEAD oops/file1 | git update-index --index-info 

to restore the index state of oops/file1.

Which leads us to the always interesting, fun and exciting:

    git ls-tree -r HEAD | git update-index --index-info 

which will undo everything except 'git add' from the index, as ls-tree -r is listing everything in the last commit.

... and also shows The Power of the Pipe, which Daniel@google was missing in recent versions of git. ;-)

Btw, this is most definitely not a documented thing and requires a bit of core git knowledge, so perhaps the "shell-scripts were good for hackers to learn what to pipe where" really *is* a very important point.

Andreas Ericsson                   [email protected]
OP5 AB                             www.op5.se

Agreed.

I learned that trick while studying the update-index source code and tried to wrap my tiny little head around the various formats --index-info accepts and how that code automatically guesses the correct format. :-)

Though I have to admit I wipped up a little test repository just to make sure what I was writing in the email worked properly; I can't say I've done it myself too many times in the past...

Still, it is very impressive, it is supported (and will be supported, I assume), and as such - worth mentioning at least in these examples everyone keeps dreaming about. Until that happened, why not mention that the output of "git ls-tree" is compatible with --index-info of "update-index"?

index f283bac..0ab9913 100644
@@ -64,6 +64,8 @@ Output Format
 

When the -z option is not used, TAB, LF, and backslash characters in pathnames are represented as \t, \n, and \\, respectively. +This output format is compatible with what "--index-info --stdin" of +git-update-index expects.

+1. Me likes, although I would amend the command-line that Shawn sent and describe what it does. Examples > descriptions everywhere else in the git docs, so it would be concise to do so.

Andreas Ericsson                   [email protected]
OP5 AB                             www.op5.se

I do not like the one that does the whole tree that much. I would think "git-read-tree -m HEAD" would be simpler and more efficient if you are reverting the whole tree.

On the other hand, I designed --index-info to be compatible with ls-tree output (it is not an accident, it was designed). In

	git ls-tree HEAD frotz | git update-index --index-info

"frotz" part does not have to be the exact path but can be a directory name. It means "revert everything in this directory".

This is quite heavy-handed and you would probably want to run update-index --refresh afterwards.

I would prefer "git update-index --reset frotz" or "git checkout --index HEAD frotz". git ls-tree|git update-index is too cryptic for me and too long for my fingers.

Then perhaps you can use "git checkout HEAD frotz", which is the simplest?

Doesn't that update the working directory as well as the index? My original question was addressed perfectly with the point at the "--index-info" switch. However, before I asked here I was looking at the man page for update-index looking for something like

  git-update-index --reset $FILE

I suppose, if it were being implemented it should be

  git-update-index --reset $COMMIT $FILE

Incidentally, this wouldn't be exactly the same as

  git-ls-tree $COMMIT $FILE | git-update-index --index-info

because the git-ls-tree version needs to be run from the root of the working directory (this bit me when I first ran it) while the (imaginary) "git-update-index --reset" would not.

Andy

Dr Andy Parkins, M Eng (hons), MIEE

Yes, sorry, see my other mail.

update-index is a plumbing that is about updating index (hence its name) and should not care what the HEAD is, and it does not even have to have _any_ head to do its work, so in that sense, "update-index --reset" is conceptually a layering violation.

Another possibility is read-tree, which is another plumbing that is about updating index from an existing tree (or three). It does not take paths limiter, so conceptually that is not too bad. We _could_ do so if we really wanted to.

But these two commands are meant to be used as building blocks, so if there are more suitable UI commands at the Porcelain layer to implement what we want to do without introducing more special cases to these plumbing commands, I would rather not touch them.

Of course; I was really only reporting that git-update-index was the place I (as a newbie) went looking for this function.

However, from a UI point of view updating the index from HEAD is just as much of an update to the index as updating it from the working directory. When I went looking, I had no idea that update-index was plumbing and not porcelain. In fact, as it's a regularly used command (git-update-index; git-commit) I'm surprised it's classed as plumbing.

As I mentioned in my original email, I was wishing for

git-reset --mixed HEAD oops/file1

But of course, that doesn't make any sense in the context of of git-reset, which is really only a HEAD manipulator with extras.

Andy

Dr Andy Parkins, M Eng (hons), MIEE

Well, reset historically is _not_ HEAD manipulator. It is the primarily Porcelain-ish to recover the index and/or the working tree that is in an undesired state.

So from that point of view, the above commandline perfectly makes sense. However, giving anything but HEAD with path makes us go "Huh?" It is unclear what this should mean:

	git-reset [--hard | --mixed] HEAD^ oops/file1

Checkout is a working tree manipulator Porcelain, and as a side effect it has always updated the index. So it might make sense to give --index-only there:

git checkout --index-only HEAD -- paths...

But from UI and workflow point of view, I think the situation under discussion is that the user wishes to _recover_ from an earlier update-index that he did not want to do. Although update-index is not designed as a UI but as a plumbing, it has been used as such (and git-status output even suggests use of it), so maybe it is not such a bad idea to bite the bullet and declare that it now _is_ a Porcelain-ish. Then we can do what you suggested (with missing <commit> defaulting to HEAD):

	git update-index --reset [<commit>] -- paths...

I am not enthused by this avenue, though. I'd like to keep low level plumbing as "tool to do only one thing and one thing well" and update-index is as low level as you would get.

On the other hand, we already have --again, so maybe we have already passed the point of no return. So I am inclined to agree with your "update-index --reset" approach, unless somebody else injects sanity into me.

I don't understand. Why wouldn't that mean reset oops/file1 to the state it had in HEAD^?

I think you're right that this is not the place - git-checkout is what one uses to update your working directory, it's only a side-effect that the index is updated - or we could argue that it is necessary that the index is updated in order that checkout can do it's job.

Actually; you've talked me out of it. Given that git-reset is already
porcelain, and none of the solutions are screaming "right"; it seems better to slightly bend git-reset than git-update-index.

Andy

Dr Andrew Parkins, M Eng (Hons), AMIEE

Path limiters everywhere in git means "do this only for paths that match this pattern, and empty path means the pattern match every path -- the command's behaviour is not different in any other aspect between the case you gave no limiter and the case you gave _all_ paths as limiters". So the other paths remain as they were (both index and working tree), and HEAD needs to be updated to HEAD^ in the above example.

While that perfect makes sense from mechanical point of view, I am not sure what it _means_ to keep some paths from now abandoned future while having some other paths reset to the rewound commit, from the point of view of end-user operation.

In other words, I do not have a good explanation on what "git reset [--hard|--mixed] <commit> <path>..." does that I can write in the documentation.

Now I admit I am not the brightest in the git circle, but if I have trouble understanding what it does, can we expect other people to grok it?

Well, now I am not sure of anything anymore ;-).

onsdag 01 november 2006 21:49 skrev Junio C Hamano:

You could refer to git-checkout although checkout doesn't have something corresponding to --mixed. The --hard option would correspond to the -f flag in checkout.

It is like "cherrypicking" content (not changes) from a particular commit.

Where did the soft option go?

Since checkout already does the work.. Is there any need for extending git-reset, other than that's where people look for this feature. The man page could be extended instead.

Isn't that exactly what the user would be asking for when they are doing a per-file reset? This is a contrived example as git makes it easier to do it in far more sensible ways; but I've done this before now in subversion... What if I want to try out some radical change? It goes like this:

x --- y --- z

Where x is some stable commit; y is a load of crazy changes; we discover that the crazy changes are all fine except for one, and so want to rollback one file, without yet commiting:

git-reset --hard HEAD^ frotz

Git would get frotz from HEAD^ and write it to the working directory and the index (or just index with --mixed).

--mixed
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action. If <path> is given then only that path will be reset to the state that <path> had in <commit-ish>. The working tree will be untouched.

--hard
Matches the working tree and index to that of the tree being switched to. Any changes to tracked files in the working tree since <commit-ish> are lost. If <path> is given then only that path will be reset in both the working tree and the index to the state that <path> had in <commit-ish>.

I do hope I'm not being presumptuous with all the above. I feel a bit gobby spouting off like I know what I'm talking about. Especially as I wrote absolutely no part of git whatsoever :-)

Andy

Dr Andrew Parkins, M Eng (Hons), AMIEE

I assume when you do the following operation your .git/HEAD points at 'y' which is already committed, and 'z' does not exist yet (it does not come into the scenario you describe below).

You forgot to mention at the same time it makes .git/HEAD point at 'x'. That's the part I am not so sure about.

Ah (lightbulb goes on). So after the above reset, you would do a "git commit" with or without -a to create a fixed-up 'y' that does not have changes to 'frotz'?

Then it sort of makes sense. --soft with paths specifier does not make much sense (paths specifier is a no-op in that case because --soft does not touch index nor working tree), but I wonder what workflow --mixed would help. It resets the index for frotz from 'x', while your crazy changes of 'y' is still in the working tree. You can "git commit" without -a to create the same fixed-up 'y' that does not have changes to 'frotz', and then keep working on 'y' to make it into less crazy.

Ok, that workflow certainly makes sense.

That's the "mechanical point of view only" description I was afraid of having. While I think I now see why they can be useful, we would need to extend the examples section to demonstrate how they help workflows to readers.

Sorry, yes, it's there merely to get in the way.

Hmmm, no I had imagined that in path mode HEAD would not be updated because that would change the whole commit instead of just the particular file.

That's the one. It was described in another response as cherry-picking content instead of commits.

Agreed. --soft + path can't have any effect because it only updates HEAD, which has no meaning in reset-path mode.

When this thread gets looked back upon, is it going to be strange that you say "yes, making crazy changes makes sense"? :-)

I must have a "mechanical point of view" brain. I can't see any further than the gear wheels.

Andy

Dr Andrew Parkins, M Eng (Hons), AMIEE

I care more about how something is useful than how faithfully something is implemented to the specification, which in turn means the specification needs to obviously indicate why it is useful.

A gadget may pick up a nearby baseball bat and jump up and down three times while holding it, but I do not want to have a description about the gadget that just says it is designed to do that. I want the the description to be obvious that everybody who reads it understands why that gadget is useful in what situations. That's why I feel the examples need to be extended.

But if I understand correctly, you are suggesting two different modes of operation, namely, with path limiters HEAD is not moved?

That is not something other git commands with pathspec does. Path limiters tell command to "do your thing only for paths that match these patterns, while you usually handle all paths; your behaviour shall otherwise not be any different in other aspects between the case you got no limiter and the case you got _all_ paths as limiters." So I do not think making path-only mode and pathless mode behave differently is a good idea from the UI point of view.

Surely if you move HEAD you have implicitly affected every path? In which case what effect did the path limiter have?

Given

x --- y --- (z--Z)

With z being the index and Z being the working directory - both uncommitted. The file foo will be different in x, y, z, and Z. We decide that z-foo is incorrect and that it was right in x; however, there are changes in Z-foo that we want to keep.

git-reset --mixed HEAD^ foo

This would reset z-foo (because --mixed) to its state in HEAD^; i.e. x-foo. If HEAD changes as well then all the rest of y will be lost - not just y-foo. Remember the original problem was a way of selectively manipulating the index without altering the working directory.

I'm perfectly happy if git-reset is not the place to do this, because git-reset is only allowed to fiddle with HEAD/index; I moved to git-reset only because you mentioned that "reset historically is _not_ HEAD manipulator".

I think we're back to square one: there is no appropriate command to take on this functionality:

git-ls-tree HEAD^ foo | git-update-index --index-info

* git-reset can't have it because it makes no sense to alter HEAD /and/ revert a file. It also occurs to me that "git-reset --hard HEAD^ foo" (using my suggested git-reset implementation) would be redundant anyway because it's the same as "git-checkout -f HEAD^ foo".
* git-checkout can't have it because it doesn't target the index.
* git-update-index can't have it because it is plumbing and doesn't know about commits, only about objects.

I'm stumped now.

Andy

Dr Andy Parkins, M Eng (hons), MIEE

In my humble opinion, git-reset is somewhat overloaded in functionality, and it takes time to explain its function to git newbies.

Why not split it into two commands, e.g.

git-rewind for manipulations with HEAD
git-reset for manipulations with index and working copy only

?

Sorry, Oops.

One should never respond to a message in an ancient thread unless one has enough time to revisit previous messages and refresh one's memory.

The original topic was about updating the index entry without touching working tree, so "co HEAD path" would not do what was wanted.

I think at the UI level, the most appropriate place would be "git reset". Checkout is a Porcelainish that is primarily about working tree and it updates the index as a side effect (from the UI point of view); you can update the working tree without modifying index or you can update both index and the working tree, but updating only index and not working tree does not belong there.

Given a commit that is different from the current HEAD, "reset" moves the HEAD and depending on hardness of the reset it updates the index and the working tree. Currently the command does not take paths limiters and means "the whole tree", but asking to update only one would logically fall as a natural extension to the current command line if we add paths limiters.

As an implementation detail of the new "reset", the ls-tree to update-index pipe could be used.

Then perhaps git-reset should do "co HEAD path" too if --index is not specified? To sum up:
- git reset HEAD path -> git checkout HEAD path
- git reset --index HEAD path -> git-ls-files HEAD path|git update-index --index-info
- git reset HEAD (without path) -> the current behaviour

Because <commit-ish> may be missing, there is some ambiguation here.

specified?

Currently "git reset --soft <commit-ish>" updates current head only, "git reset <commit-ish>" is "git reset --mixed <commit-ish>" and updates head and index, and "git reset --hard <commit-ish>" updates head, index and working tree.

The same should be the case for "git reset [--soft|--mixed|--hard] [<commit-ish>] [--] [paths...]", with the exception that it wouldn't never update current head. (So --soft with pathspec wouldn't make sense).

On the other hand git-reset is mainly about resetting current head, so perhaps git-reset isn't the best place to update fragments of index from HEAD branch.

Jakub Narebski
ShadeHawk on #git
Poland

On the other hand "reset" moves the HEAD, and with pathspec it wouldn't do that. But there is the same case for "checkout" with pathspec. And this would make "reset" and "checkout" more similar...

Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Yep, that's what I use... "git-undo-update-index" is
#!/bin/sh
git-read-tree -m -i HEAD

Luben

Absolute gold. Exactly what I wanted. Thanks so much.

Andy

Dr Andy Parkins, M Eng (hons), MIEE

I wanted to restore a single file from HEAD back to the index; Shawn Pearce gave me the answer. git-ls-tree piped to git-update-index --index-info.

This patch adds that answer to the git-update-index documentation.

---
 Documentation/git-update-index.txt |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

index 41bb7e1..5adf717 100644
@@ -215,6 +215,24 @@ $ git ls-files -s
 100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz
 ------------
 
+One particular use of --index-info is to reverse the effect of
+"git-update-index frotz":
+
+------------
+git ls-tree HEAD frotz | git update-index --index-info
+------------
+
+This makes the index hold the file frotz from HEAD rather than from the
+working copy.  Similarly:
+
+------------
+git ls-tree -r HEAD | git update-index --index-info
+------------
+
+Will undo everything except "git add" from the index, as
+"git-ls-tree -r" lists everything in the last commit.
+
+
 
 Using "assume unchanged" bit
 ----------------------------

1.4.3.3.g5bca6