{"thread":{"id":"43216","subject":"Re: Restore a single file in the index back to HEAD","startedAt":"2006-10-26T15:41:09Z","lastAt":"2006-11-02T12:47:17Z","messageCount":31,"participants":["Andy Parkins","Nguyen Thai Ngoc Duy","Robin Rosenberg","Andreas Ericsson","Jakub Narebski","Junio C Hamano","Alex Riesen","Luben Tuikov","Shawn Pearce","Salikh Zakirov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295601","messageId":"200610261641.11239.andyparkins@gmail.com","threadId":"43216","inReplyTo":null,"subject":"Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-10-26T15:41:09Z","receivedAt":"2006-10-26T15:41:09Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Hello,\n\nI have something like this:\n\n# On branch refs/heads/newmaster\n# Updated but not checked in:\n# (will commit)\n#\n# modified: oops/file1\n# modified: good/file2\n# modified: good/file3\n# modified: good/file4\n\ni.e. the index has been updated to hold oops/file1\n\nIf I then didn't want to commit oops/file1, how do I restore the HEAD \noops/file1 back to the index without doing a full reset?\n\nWhat I'm wishing for is a per file reset...\n\n git-reset --mixed HEAD oops/file1\n\n(I realise that the above is crazy, but I hope it's explaining what I want).\n\nWhen I do a git checkout -f oops/file1; I get\n\n\"git checkout: updating paths is incompatible with switching branches/forcing\nDid you intend to checkout 'oops/file1' which can not be resolved as commit?\"\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296032","messageId":"81b0412b0610260842x52413570k3971bcdc54b3ccb5@mail.gmail.com","threadId":"43216","inReplyTo":"200610261641.11239.andyparkins@gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-10-26T15:42:38Z","receivedAt":"2006-10-26T15:42:38Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":""},{"id":"296599","messageId":"200610270827.17659.andyparkins@gmail.com","threadId":"43216","inReplyTo":"81b0412b0610260842x52413570k3971bcdc54b3ccb5@mail.gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-10-27T07:27:15Z","receivedAt":"2006-10-27T07:27:15Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 October 26 16:42, Alex Riesen wrote:\n\nThanks for your suggestion.\n\n> Use \"git checkout HEAD oops/file1\"\n\nThis returned:\n\n\"git checkout: updating paths is incompatible with switching branches/forcing\nDid you intend to checkout 'oops/file1' which can not be resolved as commit?\"\n\nI'm not sure that checkout will do what I want anyway because it would \noverwrite the working directory copy of oops/file1. I want to keep the \nchanges but reset the index to have oops/file1 from HEAD.\n\nMaybe I need to say a little more about what I'm trying to do:\n\nI converted a subversion repository to git. In that repository I maintained \nmy own set of patches in one branch against an upstream branch; I'm now using \ngit-cherry-pick to pull a subset of those patches onto a new branch against \nthe upstream head. This is all working fine. The problem is that I've come \nacross a patch that should rightly be two patches instead of one. \n\nSo, I cherry-pick a patch, which updates the working directory and index, \nleaving me with...\n\n# On branch refs/heads/newmaster\n# Updated but not checked in:\n# (will commit)\n#\n# modified: oops/file1 \n# modified: good/file2\n# modified: good/file3\n# modified: good/file4\n\nInstead, what I would like is\n\n# On branch refs/heads/newmaster\n# Updated but not checked in:\n# (will commit)\n#\n# modified: good/file2\n# modified: good/file3\n# modified: good/file4\n#\n# On branch refs/heads/newmaster\n# Changed but not updated:\n# (use git-update-index to mark for commit)\n#\n# modified: oops/file1 \n\nI've actually found a way around the problem. I do git-reset HEAD, which \nrestores the index entirely but leaves the working directory. Then I \ngit-update-index the good/* set. However, it led me to wonder what the \ninverse of git-update-index is.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"297954","messageId":"20061027073834.GC29057@spearce.org","threadId":"43216","inReplyTo":"200610270827.17659.andyparkins@gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-27T07:38:34Z","receivedAt":"2006-10-27T07:38:34Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andy Parkins wrote:\n> However, it led me to wonder what the inverse of git-update-index is.\n\ngit-update-index :-)\n\nYou can use something like:\n\n git ls-tree HEAD oops/file1 | git update-index --index-info \n\nto restore the index state of oops/file1.\n\n\nWhich leads us to the always interesting, fun and exciting:\n\n git ls-tree -r HEAD | git update-index --index-info \n\nwhich will undo everything except 'git add' from the index, as\nls-tree -r is listing everything in the last commit.\n\n-- \n"},{"id":"297546","messageId":"200610270901.25091.andyparkins@gmail.com","threadId":"43216","inReplyTo":"20061027073834.GC29057@spearce.org","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-10-27T08:01:22Z","receivedAt":"2006-10-27T08:01:22Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2006 October 27 08:38, Shawn Pearce wrote:\n\n> git ls-tree HEAD oops/file1 | git update-index --index-info\n> git ls-tree -r HEAD | git update-index --index-info\n\nAbsolute gold. Exactly what I wanted. Thanks so much.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"295475","messageId":"4541BE8E.5050605@op5.se","threadId":"43216","inReplyTo":"20061027073834.GC29057@spearce.org","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-27T08:08:46Z","receivedAt":"2006-10-27T08:08:46Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Shawn Pearce wrote:\n> Andy Parkins wrote:\n>> However, it led me to wonder what the inverse of git-update-index is.\n> \n> git-update-index :-)\n> \n> You can use something like:\n> \n> git ls-tree HEAD oops/file1 | git update-index --index-info \n> \n> to restore the index state of oops/file1.\n> \n> \n> Which leads us to the always interesting, fun and exciting:\n> \n> git ls-tree -r HEAD | git update-index --index-info \n> \n> which will undo everything except 'git add' from the index, as\n> ls-tree -r is listing everything in the last commit.\n> \n\n... and also shows The Power of the Pipe, which Daniel@google was \nmissing in recent versions of git. ;-)\n\nBtw, this is most definitely not a documented thing and requires a bit \nof core git knowledge, so perhaps the \"shell-scripts were good for \nhackers to learn what to pipe where\" really *is* a very important point.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"297827","messageId":"20061027081545.GF29057@spearce.org","threadId":"43216","inReplyTo":"4541BE8E.5050605@op5.se","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-27T08:15:45Z","receivedAt":"2006-10-27T08:15:45Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Andreas Ericsson wrote:\n> Shawn Pearce wrote:\n> >Andy Parkins wrote:\n> >>However, it led me to wonder what the inverse of git-update-index is.\n> >\n> >git-update-index :-)\n> >\n> >You can use something like:\n> >\n> > git ls-tree HEAD oops/file1 | git update-index --index-info \n> >\n> >to restore the index state of oops/file1.\n> >\n> >\n> >Which leads us to the always interesting, fun and exciting:\n> >\n> > git ls-tree -r HEAD | git update-index --index-info \n> >\n> >which will undo everything except 'git add' from the index, as\n> >ls-tree -r is listing everything in the last commit.\n> >\n> \n> ... and also shows The Power of the Pipe, which Daniel@google was \n> missing in recent versions of git. ;-)\n> \n> Btw, this is most definitely not a documented thing and requires a bit \n> of core git knowledge, so perhaps the \"shell-scripts were good for \n> hackers to learn what to pipe where\" really *is* a very important point.\n\nAgreed.\n\nI learned that trick while studying the update-index source code\nand tried to wrap my tiny little head around the various formats\n--index-info accepts and how that code automatically guesses the\ncorrect format. :-)\n\nThough I have to admit I wipped up a little test repository just\nto make sure what I was writing in the email worked properly;\nI can't say I've done it myself too many times in the past...\n\n-- \n"},{"id":"298135","messageId":"200610271003.03308.andyparkins@gmail.com","threadId":"43216","inReplyTo":"200610261641.11239.andyparkins@gmail.com","subject":"[PATCH] Added description for inverting git-update-index using --index-info","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-10-27T09:03:03Z","receivedAt":"2006-10-27T09:03:03Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"I wanted to restore a single file from HEAD back to the index; Shawn Pearce\ngave me the answer. git-ls-tree piped to git-update-index --index-info.\n\nThis patch adds that answer to the git-update-index documentation.\n\nSigned-off-by: Andy Parkins \n---\n Documentation/git-update-index.txt | 18 ++++++++++++++++++\n 1 files changed, 18 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt\nindex 41bb7e1..5adf717 100644\n--- a/Documentation/git-update-index.txt\n+++ b/Documentation/git-update-index.txt\n@@ -215,6 +215,24 @@ $ git ls-files -s\n 100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2\tfrotz\n ------------\n \n+One particular use of --index-info is to reverse the effect of\n+\"git-update-index frotz\":\n+\n+------------\n+git ls-tree HEAD frotz | git update-index --index-info\n+------------\n+\n+This makes the index hold the file frotz from HEAD rather than from the\n+working copy. Similarly:\n+\n+------------\n+git ls-tree -r HEAD | git update-index --index-info\n+------------\n+\n+Will undo everything except \"git add\" from the index, as\n+\"git-ls-tree -r\" lists everything in the last commit.\n+\n+\n \n Using \"assume unchanged\" bit\n ----------------------------\n-- \n1.4.3.3.g5bca6\n"},{"id":"297942","messageId":"81b0412b0610270245w6c29b3c3va7967991f53db298@mail.gmail.com","threadId":"43216","inReplyTo":"20061027081545.GF29057@spearce.org","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-10-27T09:45:56Z","receivedAt":"2006-10-27T09:45:56Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":">> >Which leads us to the always interesting, fun and exciting:\n>> >\n>> > git ls-tree -r HEAD | git update-index --index-info\n>> >\n>> >which will undo everything except 'git add' from the index, as\n>> >ls-tree -r is listing everything in the last commit.\n>> >\n>>\n>> ... and also shows The Power of the Pipe, which Daniel@google was\n>> missing in recent versions of git. ;-)\n>>\n>> Btw, this is most definitely not a documented thing and requires a bit\n>> of core git knowledge, so perhaps the \"shell-scripts were good for\n>> hackers to learn what to pipe where\" really *is* a very important point.\n>\n> Agreed.\n\nStill, it is very impressive, it is supported (and will be supported, I assume),\nand as such - worth mentioning at least in these examples everyone keeps\ndreaming about. Until that happened, why not mention that the output\nof \"git ls-tree\" is compatible with --index-info of \"update-index\"?\n\ndiff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt\nindex f283bac..0ab9913 100644\n--- a/Documentation/git-ls-tree.txt\n+++ b/Documentation/git-ls-tree.txt\n@@ -64,6 +64,8 @@ Output Format\n\n When the `-z` option is not used, TAB, LF, and backslash characters\n in pathnames are represented as `\\t`, `\\n`, and `\\\\`, respectively.\n+This output format is compatible with what \"--index-info --stdin\" of\n+git-update-index expects.\n\n\n"},{"id":"294321","messageId":"4541D670.6000900@op5.se","threadId":"43216","inReplyTo":"81b0412b0610270245w6c29b3c3va7967991f53db298@mail.gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-10-27T09:50:40Z","receivedAt":"2006-10-27T09:50:40Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Alex Riesen wrote:\n>>> >Which leads us to the always interesting, fun and exciting:\n>>> >\n>>> > git ls-tree -r HEAD | git update-index --index-info\n>>> >\n>>> >which will undo everything except 'git add' from the index, as\n>>> >ls-tree -r is listing everything in the last commit.\n>>> >\n>>>\n>>> ... and also shows The Power of the Pipe, which Daniel@google was\n>>> missing in recent versions of git. ;-)\n>>>\n>>> Btw, this is most definitely not a documented thing and requires a bit\n>>> of core git knowledge, so perhaps the \"shell-scripts were good for\n>>> hackers to learn what to pipe where\" really *is* a very important point.\n>>\n>> Agreed.\n> \n> Still, it is very impressive, it is supported (and will be supported, I \n> assume),\n> and as such - worth mentioning at least in these examples everyone keeps\n> dreaming about. Until that happened, why not mention that the output\n> of \"git ls-tree\" is compatible with --index-info of \"update-index\"?\n> \n\n+1. Me likes, although I would amend the command-line that Shawn sent \nand describe what it does. Examples > descriptions everywhere else in \nthe git docs, so it would be concise to do so.\n\n> diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt\n> index f283bac..0ab9913 100644\n> --- a/Documentation/git-ls-tree.txt\n> +++ b/Documentation/git-ls-tree.txt\n> @@ -64,6 +64,8 @@ Output Format\n> \n> When the `-z` option is not used, TAB, LF, and backslash characters\n> in pathnames are represented as `\\t`, `\\n`, and `\\\\`, respectively.\n> +This output format is compatible with what \"--index-info --stdin\" of\n> +git-update-index expects.\n> \n> \n> Author\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294505","messageId":"7vac3igjpd.fsf@assigned-by-dhcp.cox.net","threadId":"43216","inReplyTo":"4541D670.6000900@op5.se","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-27T10:02:38Z","receivedAt":"2006-10-27T10:02:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Alex Riesen wrote:\n>>>> >Which leads us to the always interesting, fun and exciting:\n>>>> >\n>>>> > git ls-tree -r HEAD | git update-index --index-info\n>>>> >\n>>>> >which will undo everything except 'git add' from the index, as\n>>>> >ls-tree -r is listing everything in the last commit.\n>>>> >\n>>>>\n>>>> ... and also shows The Power of the Pipe, which Daniel@google was\n>>>> missing in recent versions of git. ;-)\n>>>>\n>>>> Btw, this is most definitely not a documented thing and requires a bit\n>>>> of core git knowledge, so perhaps the \"shell-scripts were good for\n>>>> hackers to learn what to pipe where\" really *is* a very important point.\n>>>\n>>> Agreed.\n>>\n>> Still, it is very impressive, it is supported (and will be\n>> supported, I assume),\n>> and as such - worth mentioning at least in these examples everyone keeps\n>> dreaming about. Until that happened, why not mention that the output\n>> of \"git ls-tree\" is compatible with --index-info of \"update-index\"?\n>\n> +1. Me likes, although I would amend the command-line that Shawn sent\n> and describe what it does. Examples > descriptions everywhere else in\n> the git docs, so it would be concise to do so.\n\nI do not like the one that does the whole tree that much. I\nwould think \"git-read-tree -m HEAD\" would be simpler and more\nefficient if you are reverting the whole tree.\n\nOn the other hand, I designed --index-info to be compatible with\nls-tree output (it is not an accident, it was designed). In\n\n\tgit ls-tree HEAD frotz | git update-index --index-info\n\n\"frotz\" part does not have to be the exact path but can be a\ndirectory name. It means \"revert everything in this directory\".\n\nThis is quite heavy-handed and you would probably want to run\nupdate-index --refresh afterwards.\n"},{"id":"296945","messageId":"20061027174511.8539.qmail@web31810.mail.mud.yahoo.com","threadId":"43216","inReplyTo":"7vac3igjpd.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Luben Tuikov","fromEmail":"ltuikov@yahoo.com","sentAt":"2006-10-27T17:45:11Z","receivedAt":"2006-10-27T17:45:11Z","isPatch":false,"sender":{"key":"ltuikov@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n> Andreas Ericsson writes:\n> \n> > Alex Riesen wrote:\n> >>>> >Which leads us to the always interesting, fun and exciting:\n> >>>> >\n> >>>> > git ls-tree -r HEAD | git update-index --index-info\n> >>>> >\n> >>>> >which will undo everything except 'git add' from the index, as\n> >>>> >ls-tree -r is listing everything in the last commit.\n> >>>> >\n> >>>>\n> >>>> ... and also shows The Power of the Pipe, which Daniel@google was\n> >>>> missing in recent versions of git. ;-)\n> >>>>\n> >>>> Btw, this is most definitely not a documented thing and requires a bit\n> >>>> of core git knowledge, so perhaps the \"shell-scripts were good for\n> >>>> hackers to learn what to pipe where\" really *is* a very important point.\n> >>>\n> >>> Agreed.\n> >>\n> >> Still, it is very impressive, it is supported (and will be\n> >> supported, I assume),\n> >> and as such - worth mentioning at least in these examples everyone keeps\n> >> dreaming about. Until that happened, why not mention that the output\n> >> of \"git ls-tree\" is compatible with --index-info of \"update-index\"?\n> >\n> > +1. Me likes, although I would amend the command-line that Shawn sent\n> > and describe what it does. Examples > descriptions everywhere else in\n> > the git docs, so it would be concise to do so.\n> \n> I do not like the one that does the whole tree that much. I\n> would think \"git-read-tree -m HEAD\" would be simpler and more\n\nYep, that's what I use... \"git-undo-update-index\" is\n #!/bin/sh\n git-read-tree -m -i HEAD\n\n Luben\n\n\n> efficient if you are reverting the whole tree.\n> \n> On the other hand, I designed --index-info to be compatible with\n> ls-tree output (it is not an accident, it was designed). In\n> \n> \tgit ls-tree HEAD frotz | git update-index --index-info\n> \n> \"frotz\" part does not have to be the exact path but can be a\n> directory name. It means \"revert everything in this directory\".\n> \n> This is quite heavy-handed and you would probably want to run\n> update-index --refresh afterwards.\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"294168","messageId":"fcaeb9bf0610312358g1176e4d8q8962b08c2e8ff2c6@mail.gmail.com","threadId":"43216","inReplyTo":"7vac3igjpd.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-11-01T07:58:54Z","receivedAt":"2006-11-01T07:58:54Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/27/06, Junio C Hamano wrote:\n> On the other hand, I designed --index-info to be compatible with\n> ls-tree output (it is not an accident, it was designed). In\n>\n> git ls-tree HEAD frotz | git update-index --index-info\n>\n> \"frotz\" part does not have to be the exact path but can be a\n> directory name. It means \"revert everything in this directory\".\n>\n> This is quite heavy-handed and you would probably want to run\n> update-index --refresh afterwards.\n\nI would prefer \"git update-index --reset frotz\" or \"git checkout\n--index HEAD frotz\". git ls-tree|git update-index is too cryptic for\nme and too long for my fingers.\n-- \n"},{"id":"295710","messageId":"7vpsc78ua3.fsf@assigned-by-dhcp.cox.net","threadId":"43216","inReplyTo":"fcaeb9bf0610312358g1176e4d8q8962b08c2e8ff2c6@mail.gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-01T08:07:16Z","receivedAt":"2006-11-01T08:07:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Nguyen Thai Ngoc Duy\" writes:\n\n> On 10/27/06, Junio C Hamano wrote:\n>> On the other hand, I designed --index-info to be compatible with\n>> ls-tree output (it is not an accident, it was designed). In\n>>\n>> git ls-tree HEAD frotz | git update-index --index-info\n>>\n>> \"frotz\" part does not have to be the exact path but can be a\n>> directory name. It means \"revert everything in this directory\".\n>>\n>> This is quite heavy-handed and you would probably want to run\n>> update-index --refresh afterwards.\n>\n> I would prefer \"git update-index --reset frotz\" or \"git checkout\n> --index HEAD frotz\". git ls-tree|git update-index is too cryptic for\n> me and too long for my fingers.\n\nThen perhaps you can use \"git checkout HEAD frotz\", which is the\nsimplest?\n\n"},{"id":"297730","messageId":"7vvelz7eg2.fsf@assigned-by-dhcp.cox.net","threadId":"43216","inReplyTo":"7vpsc78ua3.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-01T08:34:37Z","receivedAt":"2006-11-01T08:34:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> I would prefer \"git update-index --reset frotz\" or \"git checkout\n>> --index HEAD frotz\". git ls-tree|git update-index is too cryptic for\n>> me and too long for my fingers.\n>\n> Then perhaps you can use \"git checkout HEAD frotz\", which is the\n> simplest?\n\nSorry, Oops.\n\nOne should never respond to a message in an ancient thread\nunless one has enough time to revisit previous messages and\nrefresh one's memory.\n\nThe original topic was about updating the index entry without\ntouching working tree, so \"co HEAD path\" would not do what was\nwanted.\n\nI think at the UI level, the most appropriate place would be\n\"git reset\". Checkout is a Porcelainish that is primarily about\nworking tree and it updates the index as a side effect (from the\nUI point of view); you can update the working tree without\nmodifying index or you can update both index and the working\ntree, but updating only index and not working tree does not\nbelong there.\n\nGiven a commit that is different from the current HEAD, \"reset\"\nmoves the HEAD and depending on hardness of the reset it updates\nthe index and the working tree. Currently the command does not\ntake paths limiters and means \"the whole tree\", but asking to\nupdate only one would logically fall as a natural extension to\nthe current command line if we add paths limiters.\n\nAs an implementation detail of the new \"reset\", the ls-tree to\nupdate-index pipe could be used.\n"},{"id":"294974","messageId":"200611010839.35436.andyparkins@gmail.com","threadId":"43216","inReplyTo":"7vpsc78ua3.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-01T08:39:31Z","receivedAt":"2006-11-01T08:39:31Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"\n> > I would prefer \"git update-index --reset frotz\" or \"git checkout\n> > --index HEAD frotz\". git ls-tree|git update-index is too cryptic for\n> > me and too long for my fingers.\n>\n> Then perhaps you can use \"git checkout HEAD frotz\", which is the\n> simplest?\n\nDoesn't that update the working directory as well as the index? My original \nquestion was addressed perfectly with the point at the \"--index-info\" switch. \nHowever, before I asked here I was looking at the man page for update-index \nlooking for something like\n\n git-update-index --reset $FILE\n\nI suppose, if it were being implemented it should be\n\n git-update-index --reset $COMMIT $FILE\n\nIncidentally, this wouldn't be exactly the same as\n \n git-ls-tree $COMMIT $FILE | git-update-index --index-info\n\nbecause the git-ls-tree version needs to be run from the root of the working \ndirectory (this bit me when I first ran it) while the \n(imaginary) \"git-update-index --reset\" would not.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"296442","messageId":"7v4ptj7dfg.fsf@assigned-by-dhcp.cox.net","threadId":"43216","inReplyTo":"200611010839.35436.andyparkins@gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-01T08:56:35Z","receivedAt":"2006-11-01T08:56:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n>> Then perhaps you can use \"git checkout HEAD frotz\", which is the\n>> simplest?\n>\n> Doesn't that update the working directory as well as the\n> index?\n\nYes, sorry, see my other mail.\n\n> (imaginary) \"git-update-index --reset\" would not.\n\nupdate-index is a plumbing that is about updating index (hence\nits name) and should not care what the HEAD is, and it does not\neven have to have _any_ head to do its work, so in that sense,\n\"update-index --reset\" is conceptually a layering violation.\n\nAnother possibility is read-tree, which is another plumbing that\nis about updating index from an existing tree (or three). It\ndoes not take paths limiter, so conceptually that is not too\nbad. We _could_ do so if we really wanted to.\n\nBut these two commands are meant to be used as building blocks,\nso if there are more suitable UI commands at the Porcelain layer\nto implement what we want to do without introducing more special\ncases to these plumbing commands, I would rather not touch them.\n\n"},{"id":"296545","messageId":"fcaeb9bf0611010109t6281a120qeed21e0d3b29ad0c@mail.gmail.com","threadId":"43216","inReplyTo":"7vvelz7eg2.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2006-11-01T09:09:19Z","receivedAt":"2006-11-01T09:09:19Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 11/1/06, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n> >> I would prefer \"git update-index --reset frotz\" or \"git checkout\n> >> --index HEAD frotz\". git ls-tree|git update-index is too cryptic for\n> >> me and too long for my fingers.\n> >\n> > Then perhaps you can use \"git checkout HEAD frotz\", which is the\n> > simplest?\n>\n> Sorry, Oops.\n>\n> One should never respond to a message in an ancient thread\n> unless one has enough time to revisit previous messages and\n> refresh one's memory.\n>\n> The original topic was about updating the index entry without\n> touching working tree, so \"co HEAD path\" would not do what was\n> wanted.\n>\n> I think at the UI level, the most appropriate place would be\n> \"git reset\". Checkout is a Porcelainish that is primarily about\n> working tree and it updates the index as a side effect (from the\n> UI point of view); you can update the working tree without\n> modifying index or you can update both index and the working\n> tree, but updating only index and not working tree does not\n> belong there.\n\nThen perhaps git-reset should do \"co HEAD path\" too if --index is not specified?\nTo sum up:\n - git reset HEAD path -> git checkout HEAD path\n - git reset --index HEAD path -> git-ls-files HEAD path|git\nupdate-index --index-info\n - git reset HEAD (without path) -> the current behaviour\n\nBecause may be missing, there is some ambiguation here.\n-- \n"},{"id":"295622","messageId":"ei9pv0$m70$1@sea.gmane.org","threadId":"43216","inReplyTo":"7vvelz7eg2.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-01T09:38:57Z","receivedAt":"2006-11-01T09:38:57Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Given a commit that is different from the current HEAD, \"reset\"\n> moves the HEAD and depending on hardness of the reset it updates\n> the index and the working tree.  Currently the command does not\n> take paths limiters and means \"the whole tree\", but asking to\n> update only one would logically fall as a natural extension to\n> the current command line if we add paths limiters.\n> \n> As an implementation detail of the new \"reset\", the ls-tree to\n> update-index pipe could be used.\n \nOn the other hand \"reset\" moves the HEAD, and with pathspec it wouldn't\ndo that. But there is the same case for \"checkout\" with pathspec. And this\nwould make \"reset\" and \"checkout\" more similar...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296718","messageId":"200611010953.57360.andyparkins@gmail.com","threadId":"43216","inReplyTo":"7v4ptj7dfg.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-01T09:53:46Z","receivedAt":"2006-11-01T09:53:46Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 November 01 08:56, Junio C Hamano wrote:\n\n> update-index is a plumbing that is about updating index (hence\n> its name) and should not care what the HEAD is, and it does not\n> even have to have _any_ head to do its work, so in that sense,\n> \"update-index --reset\" is conceptually a layering violation.\n\nOf course; I was really only reporting that git-update-index was the place I \n(as a newbie) went looking for this function.\n\nHowever, from a UI point of view updating the index from HEAD is just as much \nof an update to the index as updating it from the working directory. When I \nwent looking, I had no idea that update-index was plumbing and not porcelain. \nIn fact, as it's a regularly used command (git-update-index; git-commit) I'm \nsurprised it's classed as plumbing.\n\n> But these two commands are meant to be used as building blocks,\n> so if there are more suitable UI commands at the Porcelain layer\n> to implement what we want to do without introducing more special\n> cases to these plumbing commands, I would rather not touch them.\n\nAs I mentioned in my original email, I was wishing for \n\n git-reset --mixed HEAD oops/file1\n\nBut of course, that doesn't make any sense in the context of of git-reset, \nwhich is really only a HEAD manipulator with extras.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294340","messageId":"eia008$aup$1@sea.gmane.org","threadId":"43216","inReplyTo":"fcaeb9bf0611010109t6281a120qeed21e0d3b29ad0c@mail.gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-01T11:22:01Z","receivedAt":"2006-11-01T11:22:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n\n> On 11/1/06, Junio C Hamano wrote:\n\n>> I think at the UI level, the most appropriate place would be\n>> \"git reset\". Checkout is a Porcelainish that is primarily about\n>> working tree and it updates the index as a side effect (from the\n>> UI point of view); you can update the working tree without\n>> modifying index or you can update both index and the working\n>> tree, but updating only index and not working tree does not\n>> belong there.\n> \n> Then perhaps git-reset should do \"co HEAD path\" too if --index is not\nspecified?\n> To sum up:\n> - git reset HEAD path -> git checkout HEAD path\n> - git reset --index HEAD path -> git-ls-files HEAD path|git\n> update-index --index-info\n> - git reset HEAD (without path) -> the current behaviour\n> \n> Because may be missing, there is some ambiguation here.\n\nCurrently \"git reset --soft \" updates current head only, \n\"git reset \" is \"git reset --mixed \" and updates\nhead and index, and \"git reset --hard \" updates head, index\nand working tree.\n\nThe same should be the case for \"git reset [--soft|--mixed|--hard]\n[] [--] [paths...]\", with the exception that it wouldn't\nnever update current head. (So --soft with pathspec wouldn't make sense).\n\nOn the other hand git-reset is mainly about resetting current head,\nso perhaps git-reset isn't the best place to update fragments of index\nfrom HEAD branch.\n-- \nJakub Narebski\nShadeHawk on #git\nPoland\n"},{"id":"294471","messageId":"7vpsc710oy.fsf@assigned-by-dhcp.cox.net","threadId":"43216","inReplyTo":"200611010953.57360.andyparkins@gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-01T18:28:13Z","receivedAt":"2006-11-01T18:28:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> As I mentioned in my original email, I was wishing for \n>\n> git-reset --mixed HEAD oops/file1\n>\n> But of course, that doesn't make any sense in the context of of git-reset, \n> which is really only a HEAD manipulator with extras.\n\nWell, reset historically is _not_ HEAD manipulator. It is the\nprimarily Porcelain-ish to recover the index and/or the working\ntree that is in an undesired state.\n\nSo from that point of view, the above commandline perfectly\nmakes sense. However, giving anything but HEAD with path makes\nus go \"Huh?\" It is unclear what this should mean:\n\n\tgit-reset [--hard | --mixed] HEAD^ oops/file1\n\nCheckout is a working tree manipulator Porcelain, and as a side\neffect it has always updated the index. So it might make sense\nto give --index-only there:\n\n\tgit checkout --index-only HEAD -- paths...\n\nBut from UI and workflow point of view, I think the situation\nunder discussion is that the user wishes to _recover_ from an\nearlier update-index that he did not want to do. Although\nupdate-index is not designed as a UI but as a plumbing, it has\nbeen used as such (and git-status output even suggests use of\nit), so maybe it is not such a bad idea to bite the bullet and\ndeclare that it now _is_ a Porcelain-ish. Then we can do what\nyou suggested (with missing defaulting to HEAD):\n\n\tgit update-index --reset [] -- paths...\n\nI am not enthused by this avenue, though. I'd like to keep low\nlevel plumbing as \"tool to do only one thing and one thing well\"\nand update-index is as low level as you would get.\n\nOn the other hand, we already have --again, so maybe we have\nalready passed the point of no return. So I am inclined to\nagree with your \"update-index --reset\" approach, unless somebody\nelse injects sanity into me.\n\n\n"},{"id":"294053","messageId":"200611012029.41869.andyparkins@gmail.com","threadId":"43216","inReplyTo":"7vpsc710oy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-01T20:29:27Z","receivedAt":"2006-11-01T20:29:27Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, November 01 18:28, Junio C Hamano wrote:\n\n> So from that point of view, the above commandline perfectly\n> makes sense. However, giving anything but HEAD with path makes\n> us go \"Huh?\" It is unclear what this should mean:\n>\n> \tgit-reset [--hard | --mixed] HEAD^ oops/file1\n\nI don't understand. Why wouldn't that mean reset oops/file1 to the state it \nhad in HEAD^?\n\n> Checkout is a working tree manipulator Porcelain, and as a side\n> effect it has always updated the index. So it might make sense\n> to give --index-only there:\n>\n> \tgit checkout --index-only HEAD -- paths...\n\nI think you're right that this is not the place - git-checkout is what one \nuses to update your working directory, it's only a side-effect that the index \nis updated - or we could argue that it is necessary that the index is updated \nin order that checkout can do it's job.\n\n> On the other hand, we already have --again, so maybe we have\n> already passed the point of no return. So I am inclined to\n> agree with your \"update-index --reset\" approach, unless somebody\n> else injects sanity into me.\n\nActually; you've talked me out of it. Given that git-reset is already \nporcelain, and none of the solutions are screaming \"right\"; it seems better \nto slightly bend git-reset than git-update-index.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"298525","messageId":"7vbqnq51v4.fsf@assigned-by-dhcp.cox.net","threadId":"43216","inReplyTo":"200611012029.41869.andyparkins@gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-01T20:49:19Z","receivedAt":"2006-11-01T20:49:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Wednesday 2006, November 01 18:28, Junio C Hamano wrote:\n>\n>> So from that point of view, the above commandline perfectly\n>> makes sense. However, giving anything but HEAD with path makes\n>> us go \"Huh?\" It is unclear what this should mean:\n>>\n>> \tgit-reset [--hard | --mixed] HEAD^ oops/file1\n>\n> I don't understand. Why wouldn't that mean reset oops/file1 to the state it \n> had in HEAD^?\n\nPath limiters everywhere in git means \"do this only for paths\nthat match this pattern, and empty path means the pattern match\nevery path -- the command's behaviour is not different in any\nother aspect between the case you gave no limiter and the case\nyou gave _all_ paths as limiters\". So the other paths remain as\nthey were (both index and working tree), and HEAD needs to be\nupdated to HEAD^ in the above example.\n\nWhile that perfect makes sense from mechanical point of view, I\nam not sure what it _means_ to keep some paths from now\nabandoned future while having some other paths reset to the\nrewound commit, from the point of view of end-user operation.\n\nIn other words, I do not have a good explanation on what \"git\nreset [--hard|--mixed] ...\" does that I can write\nin the documentation.\n\nNow I admit I am not the brightest in the git circle, but if I\nhave trouble understanding what it does, can we expect other\npeople to grok it?\n\n>> On the other hand, we already have --again, so maybe we have\n>> already passed the point of no return. So I am inclined to\n>> agree with your \"update-index --reset\" approach, unless somebody\n>> else injects sanity into me.\n>\n> Actually; you've talked me out of it. Given that git-reset is already \n> porcelain, and none of the solutions are screaming \"right\"; it seems better \n> to slightly bend git-reset than git-update-index.\n\nWell, now I am not sure of anything anymore ;-).\n"},{"id":"297283","messageId":"200611012118.11558.andyparkins@gmail.com","threadId":"43216","inReplyTo":"7vbqnq51v4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-01T21:18:10Z","receivedAt":"2006-11-01T21:18:10Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, November 01 20:49, Junio C Hamano wrote:\n\n> >> \tgit-reset [--hard | --mixed] HEAD^ oops/file1\n> While that perfect makes sense from mechanical point of view, I\n> am not sure what it _means_ to keep some paths from now\n> abandoned future while having some other paths reset to the\n> rewound commit, from the point of view of end-user operation.\n\nIsn't that exactly what the user would be asking for when they are doing a \nper-file reset? This is a contrived example as git makes it easier to do it \nin far more sensible ways; but I've done this before now in subversion... \nWhat if I want to try out some radical change? It goes like this:\n\nx --- y --- z\n\nWhere x is some stable commit; y is a load of crazy changes; we discover that \nthe crazy changes are all fine except for one, and so want to rollback one \nfile, without yet commiting:\n\n git-reset --hard HEAD^ frotz\n\nGit would get frotz from HEAD^ and write it to the working directory and the \nindex (or just index with --mixed).\n\n> In other words, I do not have a good explanation on what \"git\n> reset [--hard|--mixed] ...\" does that I can write\n> in the documentation.\n\n --mixed\n Resets the index but not the working tree (i.e., the changed files are\n preserved but not marked for commit) and reports what has not been\n updated. This is the default action. If is given then only that\n path will be reset to the state that had in . The\n working tree will be untouched.\n\n --hard\n Matches the working tree and index to that of the tree being switched to.\n Any changes to tracked files in the working tree since are\n lost. If is given then only that path will be reset in both the\n working tree and the index to the state that had in .\n\n> Well, now I am not sure of anything anymore ;-).\n\nI do hope I'm not being presumptuous with all the above. I feel a bit gobby \nspouting off like I know what I'm talking about. Especially as I wrote \nabsolutely no part of git whatsoever :-)\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"297274","messageId":"7vodrq251z.fsf@assigned-by-dhcp.cox.net","threadId":"43216","inReplyTo":"200611012118.11558.andyparkins@gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-01T22:08:40Z","receivedAt":"2006-11-01T22:08:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Wednesday 2006, November 01 20:49, Junio C Hamano wrote:\n>\n>> >> \tgit-reset [--hard | --mixed] HEAD^ oops/file1\n>> While that perfect makes sense from mechanical point of view, I\n>> am not sure what it _means_ to keep some paths from now\n>> abandoned future while having some other paths reset to the\n>> rewound commit, from the point of view of end-user operation.\n>\n> Isn't that exactly what the user would be asking for when they are doing a \n> per-file reset? This is a contrived example as git makes it easier to do it \n> in far more sensible ways; but I've done this before now in subversion... \n> What if I want to try out some radical change? It goes like this:\n>\n> x --- y --- z\n\nI assume when you do the following operation your .git/HEAD\npoints at 'y' which is already committed, and 'z' does not exist\nyet (it does not come into the scenario you describe below).\n\n> Where x is some stable commit; y is a load of crazy changes;\n> we discover that the crazy changes are all fine except for\n> one, and so want to rollback one file, without yet commiting:\n>\n> git-reset --hard HEAD^ frotz\n>\n> Git would get frotz from HEAD^ and write it to the working directory and the \n> index (or just index with --mixed).\n\nYou forgot to mention at the same time it makes .git/HEAD point\nat 'x'. That's the part I am not so sure about.\n\nAh (lightbulb goes on). So after the above reset, you would do\na \"git commit\" with or without -a to create a fixed-up 'y' that\ndoes not have changes to 'frotz'?\n\nThen it sort of makes sense. --soft with paths specifier does\nnot make much sense (paths specifier is a no-op in that case\nbecause --soft does not touch index nor working tree), but I\nwonder what workflow --mixed would help. It resets the index\nfor frotz from 'x', while your crazy changes of 'y' is still in\nthe working tree. You can \"git commit\" without -a to create the\nsame fixed-up 'y' that does not have changes to 'frotz', and\nthen keep working on 'y' to make it into less crazy.\n\nOk, that workflow certainly makes sense.\n\n>> In other words, I do not have a good explanation on what \"git\n>> reset [--hard|--mixed] ...\" does that I can write\n>> in the documentation.\n>\n> --mixed\n> Resets the index but not the working tree (i.e., the changed files are\n> preserved but not marked for commit) and reports what has not been\n> updated. This is the default action. If is given then only that\n> path will be reset to the state that had in . The\n> working tree will be untouched.\n>\n> --hard\n> Matches the working tree and index to that of the tree being switched to.\n> Any changes to tracked files in the working tree since are\n> lost. If is given then only that path will be reset in both the\n> working tree and the index to the state that had in .\n\nThat's the \"mechanical point of view only\" description I was\nafraid of having. While I think I now see why they can be\nuseful, we would need to extend the examples section to\ndemonstrate how they help workflows to readers.\n\n"},{"id":"294304","messageId":"200611012327.08967.robin.rosenberg.lists@dewire.com","threadId":"43216","inReplyTo":"7vbqnq51v4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-11-01T22:27:08Z","receivedAt":"2006-11-01T22:27:08Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 01 november 2006 21:49 skrev Junio C Hamano:\n> Andy Parkins writes:\n> > On Wednesday 2006, November 01 18:28, Junio C Hamano wrote:\n> >> So from that point of view, the above commandline perfectly\n> >> makes sense. However, giving anything but HEAD with path makes\n> >> us go \"Huh?\" It is unclear what this should mean:\n> >>\n> >> \tgit-reset [--hard | --mixed] HEAD^ oops/file1\n> >\n> > I don't understand. Why wouldn't that mean reset oops/file1 to the state\n> > it had in HEAD^?\n>\n> Path limiters everywhere in git means \"do this only for paths\n> that match this pattern, and empty path means the pattern match\n> every path -- the command's behaviour is not different in any\n> other aspect between the case you gave no limiter and the case\n> you gave _all_ paths as limiters\". So the other paths remain as\n> they were (both index and working tree), and HEAD needs to be\n> updated to HEAD^ in the above example.\n>\n> While that perfect makes sense from mechanical point of view, I\n> am not sure what it _means_ to keep some paths from now\n> abandoned future while having some other paths reset to the\n> rewound commit, from the point of view of end-user operation.\n>\n> In other words, I do not have a good explanation on what \"git\n> reset [--hard|--mixed] ...\" does that I can write\n> in the documentation.\n\nYou could refer to git-checkout although checkout doesn't have something \ncorresponding to --mixed. The --hard option would correspond to the -f flag \nin checkout.\n\nIt is like \"cherrypicking\" content (not changes) from a particular commit. \n\nWhere did the soft option go? \n\nSince checkout already does the work.. Is there any need for extending \ngit-reset, other than that's where people look for this feature. The man page \ncould be extended instead.\n\n"},{"id":"295891","messageId":"200611012309.42675.andyparkins@gmail.com","threadId":"43216","inReplyTo":"7vodrq251z.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-01T23:09:41Z","receivedAt":"2006-11-01T23:09:41Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, November 01 22:08, Junio C Hamano wrote:\n\n> > x --- y --- z\n>\n> I assume when you do the following operation your .git/HEAD\n> points at 'y' which is already committed, and 'z' does not exist\n> yet (it does not come into the scenario you describe below).\n\nSorry, yes, it's there merely to get in the way.\n\n> You forgot to mention at the same time it makes .git/HEAD point\n> at 'x'. That's the part I am not so sure about.\n\nHmmm, no I had imagined that in path mode HEAD would not be updated because \nthat would change the whole commit instead of just the particular file.\n\n> Ah (lightbulb goes on). So after the above reset, you would do\n> a \"git commit\" with or without -a to create a fixed-up 'y' that\n> does not have changes to 'frotz'?\n\nThat's the one. It was described in another response as cherry-picking \ncontent instead of commits.\n\n> Then it sort of makes sense. --soft with paths specifier does\n> not make much sense (paths specifier is a no-op in that case\n> because --soft does not touch index nor working tree), but I\n\nAgreed. --soft + path can't have any effect because it only updates HEAD, \nwhich has no meaning in reset-path mode.\n\n> Ok, that workflow certainly makes sense.\n\nWhen this thread gets looked back upon, is it going to be strange that you \nsay \"yes, making crazy changes makes sense\"? :-)\n\n> That's the \"mechanical point of view only\" description I was\n> afraid of having. While I think I now see why they can be\n\nI must have a \"mechanical point of view\" brain. I can't see any further than \nthe gear wheels.\n\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"294530","messageId":"7vejsmzqh6.fsf@assigned-by-dhcp.cox.net","threadId":"43216","inReplyTo":"200611012309.42675.andyparkins@gmail.com","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-01T23:39:33Z","receivedAt":"2006-11-01T23:39:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Wednesday 2006, November 01 22:08, Junio C Hamano wrote:\n>\n>> That's the \"mechanical point of view only\" description I was\n>> afraid of having. While I think I now see why they can be\n>\n> I must have a \"mechanical point of view\" brain. I can't see\n> any further than the gear wheels.\n\nI care more about how something is useful than how faithfully\nsomething is implemented to the specification, which in turn\nmeans the specification needs to obviously indicate why it is\nuseful.\n\nA gadget may pick up a nearby baseball bat and jump up and down\nthree times while holding it, but I do not want to have a\ndescription about the gadget that just says it is designed to do\nthat. I want the the description to be obvious that everybody\nwho reads it understands why that gadget is useful in what\nsituations. That's why I feel the examples need to be extended.\n\nBut if I understand correctly, you are suggesting two different\nmodes of operation, namely, with path limiters HEAD is not\nmoved?\n\nThat is not something other git commands with pathspec does.\nPath limiters tell command to \"do your thing only for paths that\nmatch these patterns, while you usually handle all paths; your\nbehaviour shall otherwise not be any different in other aspects\nbetween the case you got no limiter and the case you got _all_\npaths as limiters.\" So I do not think making path-only mode and\npathless mode behave differently is a good idea from the UI\npoint of view.\n"},{"id":"296212","messageId":"200611020844.12357.andyparkins@gmail.com","threadId":"43216","inReplyTo":"7vejsmzqh6.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-02T08:44:10Z","receivedAt":"2006-11-02T08:44:10Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 November 01 23:39, Junio C Hamano wrote:\n\n> That is not something other git commands with pathspec does.\n> Path limiters tell command to \"do your thing only for paths that\n> match these patterns, while you usually handle all paths; your\n> behaviour shall otherwise not be any different in other aspects\n> between the case you got no limiter and the case you got _all_\n> paths as limiters.\" So I do not think making path-only mode and\n> pathless mode behave differently is a good idea from the UI\n> point of view.\n\nSurely if you move HEAD you have implicitly affected every path? In which \ncase what effect did the path limiter have?\n\nGiven\n\n x --- y --- (z--Z)\n\nWith z being the index and Z being the working directory - both uncommitted. \nThe file foo will be different in x, y, z, and Z. We decide that z-foo is \nincorrect and that it was right in x; however, there are changes in Z-foo \nthat we want to keep.\n\n git-reset --mixed HEAD^ foo\n\nThis would reset z-foo (because --mixed) to its state in HEAD^; i.e. x-foo. \nIf HEAD changes as well then all the rest of y will be lost - not just y-foo. \nRemember the original problem was a way of selectively manipulating the index \nwithout altering the working directory.\n\nI'm perfectly happy if git-reset is not the place to do this, because \ngit-reset is only allowed to fiddle with HEAD/index; I moved to git-reset \nonly because you mentioned that \"reset historically is _not_ HEAD \nmanipulator\".\n\nI think we're back to square one: there is no appropriate command to take on \nthis functionality:\n\n git-ls-tree HEAD^ foo | git-update-index --index-info\n\n * git-reset can't have it because it makes no sense to alter HEAD /and/\n revert a file. It also occurs to me that \"git-reset --hard HEAD^ foo\"\n (using my suggested git-reset implementation) would be redundant anyway\n because it's the same as \"git-checkout -f HEAD^ foo\".\n * git-checkout can't have it because it doesn't target the index.\n * git-update-index can't have it because it is plumbing and doesn't know\n about commits, only about objects.\n\nI'm stumped now.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"298300","messageId":"eicpch$7ar$2@sea.gmane.org","threadId":"43216","inReplyTo":"7vbqnq51v4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Restore a single file in the index back to HEAD","fromName":"Salikh Zakirov","fromEmail":"salikh.zakirov@intel.com","sentAt":"2006-11-02T12:47:17Z","receivedAt":"2006-11-02T12:47:17Z","isPatch":false,"sender":{"key":"salikh.zakirov@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> In other words, I do not have a good explanation on what \"git\n> reset [--hard|--mixed] ...\" does that I can write\n> in the documentation.\n\nIn my humble opinion, git-reset is somewhat overloaded in functionality,\nand it takes time to explain its function to git newbies.\n\nWhy not split it into two commands, e.g.\n\n git-rewind for manipulations with HEAD\n git-reset for manipulations with index and working copy only\n\n?\n"}]}