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
APAndy Parkins <andyparkins@gmail.com>
Date
Nov 1, 2006, 21:18 UTC
Message-ID
<200611012118.11558.andyparkins@gmail.com>
In-Reply-To
<7vbqnq51v4.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006, November 01 20:49, Junio C Hamano wrote:
Show 5 quoted lines
> >> 	git-reset [--hard | --mixed] HEAD^ oops/file1
> 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.

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).

> 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.
 --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>.
> Well, now I am not sure of anything anymore ;-).

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
Previous: Junio C HamanoNext: Junio C Hamano
Message 24 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.