{"thread":{"id":"1609","subject":"\"git reset\" and newly created files.","startedAt":"2005-08-21T19:31:19Z","lastAt":"2005-08-22T08:17:26Z","messageCount":3,"participants":["Junio C Hamano","Sam Ravnborg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7609","messageId":"7vbr3rccjc.fsf@assigned-by-dhcp.cox.net","threadId":"1609","inReplyTo":null,"subject":"\"git reset\" and newly created files.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-21T19:31:19Z","receivedAt":"2005-08-21T19:31:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When you made a mistake and committed a set of incomplete\nchanges, the \"git reset\" command comes handy.\n\n    ... Edit, compile, and test.\n    $ git commit -s -m 'The perfect change.'\n    ... Test again, OOPS it fails --- it was not perfect.\n    $ git reset HEAD^\n    foo: needs update\n    bar: needs update\n\nThe commit object name for the botched commit is kept in the\n$GIT_DIR/ORIG_HEAD file, the HEAD commit and the index file are\n\"reset\" to the commit before ORIG_HEAD.  The files in the\nworking tree are not touched and they are the same as what are\nin ORIG_HEAD.  The command tells which files in the working tree\nare different from the HEAD commit.\n\nSo you would naturally be tempted to do this:\n\n    ... Re-edit, compile, and test.  This time it is perfect.\n    $ git commit -a -C ORIG_HEAD\n\nWell, not really.  You can lose any file newly created in\nORIG_HEAD this way.  Instead, you need to do this:\n\n    ... Re-edit, compile, and test.  This time it is perfect.\n    $ git add <whatever file you have changed>\n    $ git commit -a -C ORIG_HEAD\n\nDo people find this a big problem?\n\nTechnically, what \"git reset\" does is correct, because its\ndefinition says the index file is reset to what was in HEAD,\nwhich did not know about the files added by the ORIG_HEAD, and\nthere is no way for it to keep an eye on the file you wanted to\nadd in the botched ORIG_HEAD commit.\n\nBut it does not _feel_ right.\n\nThis relates to the fact that there currently is no way to\nrecord \"intent to add\" (aka \"please keep an eye on\") in the\nindex file.  I think we could solve this with something like\nthis:\n\n    $ git-update-cache --add-maybe foo\n    $ git status\n    # Changed but not updated:\n    #   (use git-update-cache to mark for commit)\n    #\n    #       new file: foo\n    $ git-update-cache --refresh\n    foo: needs update\n    $ git-update-cache foo\n    $ git status\n    # Updated but not checked in:\n    #   (will commit)\n    #\n    #       new file: foo\n\nThe \"git reset\" command should be able to detect the paths found\nin ORIG_HEAD but lacking in HEAD, reset the index to HEAD and\nsay \"git-update-cache --add-maybe\" for such paths.\n\nHmm?\n"},{"id":"7614","messageId":"20050821214605.GA4134@mars.ravnborg.org","threadId":"1609","inReplyTo":"7vbr3rccjc.fsf@assigned-by-dhcp.cox.net","subject":"Re: \"git reset\" and newly created files.","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2005-08-21T21:46:05Z","receivedAt":"2005-08-21T21:46:05Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"> \n> So you would naturally be tempted to do this:\n> \n>     ... Re-edit, compile, and test.  This time it is perfect.\n>     $ git commit -a -C ORIG_HEAD\n> \n> Well, not really.  You can lose any file newly created in\n> ORIG_HEAD this way.  Instead, you need to do this:\n> \n>     ... Re-edit, compile, and test.  This time it is perfect.\n>     $ git add <whatever file you have changed>\n>     $ git commit -a -C ORIG_HEAD\n> \n> Do people find this a big problem?\n\nI often do some maybe not that brilliant changes in my tree,\nand when I then ask git to reset these I expect git to reset\neverything.\n\nAfter a git-reset HEAD^ I really expect git to have rewinded back till\nwhere I started with no files added whatsoever.\n\n>From the matter of least suprise git should not remember files added,\none have to do that by themself again if needed.\n\n\tSam\n"},{"id":"7625","messageId":"7vslx29yi1.fsf@assigned-by-dhcp.cox.net","threadId":"1609","inReplyTo":"20050821214605.GA4134@mars.ravnborg.org","subject":"Re: \"git reset\" and newly created files.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-22T08:17:26Z","receivedAt":"2005-08-22T08:17:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Ravnborg <sam@ravnborg.org> writes:\n\n>> So you would naturally be tempted to do this:\n>> \n>>     ... Re-edit, compile, and test.  This time it is perfect.\n>>     $ git commit -a -C ORIG_HEAD\n>> \n>> Well, not really.  You can lose any file newly created in\n>> ORIG_HEAD this way.  Instead, you need to do this:\n>> \n>>     ... Re-edit, compile, and test.  This time it is perfect.\n>>     $ git add <whatever file you have changed>\n>>     $ git commit -a -C ORIG_HEAD\n>> \n>> Do people find this a big problem?\n>\n> I often do some maybe not that brilliant changes in my tree,\n> and when I then ask git to reset these I expect git to reset\n> everything.\n>\n> After a git-reset HEAD^ I really expect git to have rewinded back till\n> where I started with no files added whatsoever.\n\nThat is another thing I initially expected from the \"git reset\"\ncommand, but I do not think that is what this command is about.\nIt is about reverting your working tree and index file to the\nstate just before you make your commit to create the botched\ncommit, so that you can make minor fixes and recommit.\n\nViewing it that way, it might even be a good idea to \"git add\"\nthe files that are in ORIG_HEAD but not in the head you are\n\"resetting\" to.\n\n> From the matter of least suprise git should not remember files added,\n> one have to do that by themself again if needed.\n\nWhat I was getting at was that doing things that way means new\nfiles and modified files are handled inconsistently.  With the\ncurrent implementation, git \"remembers\" the files modified, but\nnot files added.  And if the purpose of \"reset\" is to eventually\nre-commit, it would be useful if git remembers both, not just\nmodified files.\n\nOne way to achieve that would be \"git-update-cache --add-maybe\"\nI talked about in the original message, but at least something\nlike the following would still be an improvement.  Instead of\nechoing the output from diff-tree, we might even be better off\nif we just feed it to \"xargs git-update-cache --add\".\n\n------------\n[PATCH] Remind the user of \"about to be lost\" files. \n\nFiles that are in the current HEAD but not in the head we are\nresetting to can easily be lost when \"git reset HEAD^\" is\nfollowed by re-edit and \"git commit\".\n\nThis patch reminds the user about those files.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\ndiff --git a/git-reset-script b/git-reset-script\n--- a/git-reset-script\n+++ b/git-reset-script\n@@ -6,6 +6,16 @@ git-read-tree --reset \"$rev\" && {\n \tif orig=$(git-rev-parse --verify HEAD 2>/dev/null)\n \tthen\n \t\techo \"$orig\" >\"$GIT_DIR/ORIG_HEAD\"\n+\n+\t\t# Remind the user about files that are in ORIG_HEAD\n+\t\t# but not in $rev.  We would really want to do\n+\t\t# \"git-update-cache --add-maybe\" on these paths, but\n+\t\t# that is not available (yet).\n+\t\tgit-diff-tree -r --diff-filter=D $rev ORIG_HEAD |\n+\t\twhile path\n+\t\tdo\n+\t\t\techo \"$path: needs add\"\n+\t\tdone\n \tfi\n \techo \"$rev\" > \"$GIT_DIR/HEAD\"\n }\n"}]}