git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Restore a single file in the index back to HEAD

From
Junio C Hamano <junkio@cox.net>
Date
Nov 1, 2006, 18:28 UTC
Message-ID
<7vpsc710oy.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<200611010953.57360.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
Show 6 quoted lines
> 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.

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.

Previous: Andy ParkinsNext: Andy Parkins
Message 21 of 31 in “Restore a single file in the index back to HEAD”
  1. Andy ParkinsOct 26, 2006
  2. Alex RiesenOct 26, 2006
  3. Andy ParkinsOct 27, 2006
  4. Shawn PearceOct 27, 2006
  5. Andy ParkinsOct 27, 2006
  6. Andreas EricssonOct 27, 2006
  7. Shawn PearceOct 27, 2006
  8. Alex RiesenOct 27, 2006
  9. Andreas EricssonOct 27, 2006
  10. Junio C HamanoOct 27, 2006
  11. Luben TuikovOct 27, 2006
  12. Nguyen Thai Ngoc DuyNov 1, 2006
  13. Junio C HamanoNov 1, 2006
  14. Junio C HamanoNov 1, 2006
  15. Nguyen Thai Ngoc DuyNov 1, 2006
  16. Jakub NarebskiNov 1, 2006
  17. Jakub NarebskiNov 1, 2006
  18. Andy ParkinsNov 1, 2006
  19. Junio C HamanoNov 1, 2006
  20. Andy ParkinsNov 1, 2006
  21. Junio C HamanoNov 1, 2006
  22. Andy ParkinsNov 1, 2006
  23. Junio C HamanoNov 1, 2006
  24. Andy ParkinsNov 1, 2006
  25. Junio C HamanoNov 1, 2006
  26. Andy ParkinsNov 1, 2006
  27. Junio C HamanoNov 1, 2006
  28. Andy ParkinsNov 2, 2006
  29. Robin RosenbergNov 1, 2006
  30. Salikh ZakirovNov 2, 2006
  31. Added description for inverting git-update-index using --index-infoAndy Parkins, Oct 27, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.