{"thread":{"id":"1615","subject":"[PATCH] Introduce \"reset type\" flag to \"git reset\"","startedAt":"2005-08-23T01:07:30Z","lastAt":"2005-08-24T18:35:50Z","messageCount":7,"participants":["Junio C Hamano","Sam Ravnborg","Yasushi SHOJI"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"7635","messageId":"7vu0hhzcj1.fsf@assigned-by-dhcp.cox.net","threadId":"1615","inReplyTo":null,"subject":"[PATCH] Introduce \"reset type\" flag to \"git reset\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-23T01:07:30Z","receivedAt":"2005-08-23T01:07:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I have been feeling that the current behaviour of \"git reset\" is\nnot quite optimal, but so far could not express exactly what I\nfelt was wrong with it.  This patch clarifies it.\n\nThere are at least two situations you may want to \"reset\" your\nworking tree.\n\n1. You made a mess in your working tree.  You want to switch\n   back to a known good state and start over.  This mess may be\n   a result of your own editing, a merge that had too many\n   conflicting changes that you do not feel like to resolve by\n   hand at this moment, or a botched application of a patch you\n   received from somewhere.\n\n   In this case, you would want to have \"git reset HEAD\" reset\n   the index file to the tree read from the HEAD commit and the\n   files in the working tree to match index (i.e. \"git status\"\n   should say \"Nothing to commit\", without any \"unrecorded\n   changes\").\n\n   The current behaviour leaves the files in the working tree\n   intact, which requires you to run \"git checkout -f\".  Also\n   you need to remember \"rm -f\" any files that the botched patch\n   may have left in the working tree if the purpose of this\n   \"reset\" is to attempt to apply it again; most likely the\n   patch would fail if such a file is left behind.\n\n2. You have discovered that commits you made earlier need to be\n   reorganized.  The simplest example is to undo the last\n   commit, re-edit some files, and redo the commit.  Another\n   simple eample is to undo the last two commits, and commit the\n   changes in those two commits as a single commit.\n\n   In this case, you would want to have \"git reset HEAD^\" reset\n   the $GIT_DIR/HEAD to the commit object name of the parent\n   commit of the current commit (i.e. rewinding one commit),\n   leave the index file and the files in the working tree in a\n   state where you can easily make a commit that records a tree\n   that resembles what you have in the current index file and\n   the working tree.\n\n   The current behaviour is almost OK for this purpose, except\n   that you need to find which files you need to manually run\n   \"git add\" yourself.  They are files that are in the original\n   HEAD commit and not in the commit you are resetting to.\n\nThe default without the type flag is to do \"--mixed\", which is\nthe current behaviour.\n\n    $ git reset [ --hard | --soft | --mixed ] [ <commit-ish> ]\n\nA hard reset would be used for 1 and works in this way:\n\n    (1) remember the set of paths that appear in the current\n        index file (which may even have unmerged entries) and\n\tthe current $GIT_DIR/HEAD commit.\n\n    (2) \"read-tree --reset\" the specified <commit-ish> (default\n        to HEAD), followed by \"checkout-cache -f -u -a\".\n\n    (3) remove any files that appear in (1) but not in\n        <commit-ish> from the working tree.\n\n    (4) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update\n        $GIT_DIR/HEAD with the specified <commit-ish>.\n\n    (5) remove leftover $GIT_DIR/MERGE_HEAD\n\nA soft reset would be used for 2 and works in this way:\n\n    (1) Make sure that the index file is merged and we do not\n        have MERGE_HEAD; otherwise it does not make sense to do\n        soft reset.\n\n    (2) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update\n        $GIT_DIR/HEAD with the specified <commit-ish>.\n\nNote that with the current behaviour, \"git diff\" is the way to\nsee what could be committed immediately after \"git reset\".  With\nthe \"soft reset\" described here you would need to say \"git diff\nHEAD\" to find that out.\n\nI am not sure what mixed reset (the current behaviour) is good\nfor.  If nobody comes up with a good use case it may not be a\nbad idea to remove it.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n git-reset-script |   96 +++++++++++++++++++++++++++++++++++++++++++++++++++---\n 1 files changed, 90 insertions(+), 6 deletions(-)\n\nc0e136c6ab8481fb4927f033bb7da105b7417207\ndiff --git a/git-reset-script b/git-reset-script\n--- a/git-reset-script\n+++ b/git-reset-script\n@@ -1,13 +1,97 @@\n #!/bin/sh\n . git-sh-setup-script || die \"Not a git archive\"\n+\n+tmp=/var/tmp/reset.$$\n+trap 'rm -f $tmp-*' 0 1 2 3 15\n+\n+reset_type=--mixed\n+case \"$1\" in\n+--mixed | --soft | --hard)\n+\treset_type=\"$1\"\n+\tshift\n+\t;;\n+esac\n+\n rev=$(git-rev-parse --verify --default HEAD \"$@\") || exit\n rev=$(git-rev-parse --verify $rev^0) || exit\n-git-read-tree --reset \"$rev\" && {\n-\tif orig=$(git-rev-parse --verify HEAD 2>/dev/null)\n+\n+# We need to remember the set of paths that _could_ be left\n+# behind before a hard reset, so that we can remove them.\n+if test \"$reset_type\" = \"--hard\"\n+then\n+\t{\n+\t\tgit-ls-files --stage -z\n+\t\tgit-rev-parse --verify HEAD 2>/dev/null &&\n+\t\tgit-ls-tree -r -z HEAD\n+\t} | perl -e '\n+\t    use strict;\n+\t    my %seen;\n+\t    $/ = \"\\0\";\n+\t    while (<>) {\n+\t\tchomp;\n+\t\tmy ($info, $path) = split(/\\t/, $_);\n+\t\tnext if ($info =~ / tree /);\n+\t\tif (!$seen{$path}) {\n+\t\t\t$seen{$path} = 1;\n+\t\t\tprint \"$path\\0\";\n+\t\t}\n+\t    }\n+\t' >$tmp-exists\n+fi\n+\n+# Soft reset does not touch the index file nor the working tree\n+# at all, but requires them in a good order.  Other resets reset\n+# the index file to the tree object we are switching to.\n+if test \"$reset_type\" = \"--soft\"\n+then\n+\tif test -f \"$GIT_DIR/MERGE_HEAD\" ||\n+\t   test \"\" != \"$(git-ls-files --unmerged)\"\n \tthen\n-\t\techo \"$orig\" >\"$GIT_DIR/ORIG_HEAD\"\n+\t\tdie \"Cannot do a soft reset in the middle of a merge.\"\n \tfi\n-\techo \"$rev\" > \"$GIT_DIR/HEAD\"\n-}\n-git-update-cache --refresh\n+else\n+\tgit-read-tree --reset \"$rev\" || exit\n+fi\n+\n+# Any resets update HEAD to the head being switched to.\n+if orig=$(git-rev-parse --verify HEAD 2>/dev/null)\n+then\n+\techo \"$orig\" >\"$GIT_DIR/ORIG_HEAD\"\n+else\n+\trm -f \"$GIT_DIR/ORIG_HEAD\"\n+fi\n+echo \"$rev\" >\"$GIT_DIR/HEAD\"\n+\n+case \"$reset_type\" in\n+--hard )\n+\t# Hard reset matches the working tree to that of the tree\n+\t# being switched to.\n+\tgit-checkout-cache -f -u -q -a\n+\tgit-ls-files --cached -z |\n+\tperl -e '\n+\t\tuse strict;\n+\t\tmy (%keep, $fh);\n+\t\t$/ = \"\\0\";\n+\t\twhile (<STDIN>) {\n+\t\t\tchomp;\n+\t\t\t$keep{$_} = 1;\n+\t\t}\n+\t\topen $fh, \"<\", $ARGV[0]\n+\t\t\tor die \"cannot open $ARGV[0]\";\n+\t\twhile (<$fh>) {\n+\t\t\tchomp;\n+\t\t\tif (! exists $keep{$_}) {\n+\t\t\t\tprint \"$_\\0\";\n+\t\t\t}\n+\t\t}\n+\t' $tmp-exists | xargs -0 rm -v -f --\n+\t;;\n+--soft )\n+\t;; # Nothing else to do\n+--mixed )\n+\t# Report what has not been updated.\n+\tgit-update-cache --refresh\n+\t;;\n+esac\n+\n rm -f \"$GIT_DIR/MERGE_HEAD\"\n"},{"id":"7662","messageId":"20050823202637.GA8061@mars.ravnborg.org","threadId":"1615","inReplyTo":"7vu0hhzcj1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce \"reset type\" flag to \"git reset\"","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2005-08-23T20:26:37Z","receivedAt":"2005-08-23T20:26:37Z","isPatch":true,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"> I am not sure what mixed reset (the current behaviour) is good\n> for.  If nobody comes up with a good use case it may not be a\n> bad idea to remove it.\nUsing the principle of minimum suprise the --mixed should be removed.\n--soft - undo the commit leaving all changes.\n--hard - undo the commit and removing all changes\n\nI'm a cogito user so not used to got options.\nBut --soft, --hard looks rather confusing to me.\n\nSomething like --force or --prune may be a bit more intuitive, and let\ndefault behaviour be the one you name --soft for now.\n\nI think it would make sense to be able to specify the topmost SHA1 (or \nHEAD:5 or HEAD^^^^^) from where the reset should start.\n\n\tSam\n"},{"id":"7675","messageId":"7vacj8nw5v.fsf@assigned-by-dhcp.cox.net","threadId":"1615","inReplyTo":"20050823202637.GA8061@mars.ravnborg.org","subject":"Re: [PATCH] Introduce \"reset type\" flag to \"git reset\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-23T22:08:44Z","receivedAt":"2005-08-23T22:08:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Ravnborg <sam@ravnborg.org> writes:\n\n> But --soft, --hard looks rather confusing to me.\n>\n> Something like --force or --prune may be a bit more intuitive, and let\n> default behaviour be the one you name --soft for now.\n\nI do not have objections to removing --mixed, but I do not find\n--force/--prune any less confusing than --soft/--hard.  Its just\na terminology so once people get used to it anything would do.\nBut I agree that we need to come up with a good name for them.\nI do not think --force/--prune is it, though.\n\n> I think it would make sense to be able to specify the topmost SHA1 (or \n> HEAD:5 or HEAD^^^^^) from where the reset should start.\n\n\"git reset --hard HEAD~5\" should work.  Sorry, the colon \":\"\nturns out to be confusing to refspec notation <src>:<dst> used\nin fetch/push and was replaced with a tilde \"~\" some time ago.\n"},{"id":"7683","messageId":"87y86s2nvi.wl@mail2.atmark-techno.com","threadId":"1615","inReplyTo":"7vacj8nw5v.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce \"reset type\" flag to \"git reset\"","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2005-08-24T00:13:21Z","receivedAt":"2005-08-24T00:13:21Z","isPatch":true,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"At Tue, 23 Aug 2005 15:08:44 -0700,\nJunio C Hamano wrote:\n> \n> Sam Ravnborg <sam@ravnborg.org> writes:\n> \n> > But --soft, --hard looks rather confusing to me.\n> >\n> > Something like --force or --prune may be a bit more intuitive, and let\n> > default behaviour be the one you name --soft for now.\n> \n> I do not have objections to removing --mixed, but I do not find\n> --force/--prune any less confusing than --soft/--hard.  Its just\n> a terminology so once people get used to it anything would do.\n> But I agree that we need to come up with a good name for them.\n> I do not think --force/--prune is it, though.\n\nI think the point is \"what is the target?\".\n\nI believe \"git reset\" is targeting at the index file and only the\nindex file and nothing more. it's that simple.\n\nwhat we want instead is a command to sync/reset/revert both index and\ntree to know working point.  so this isn't core plumbing but as a user\nof git, i'm sure it's very handy to have it.\n\n--soft one is simple to think, so i'm starting with this one. let's\nassume that, as you described in the original post, this one is\nintended to be used to rework on the work _you_ have before.  that\nmeans that _you_ know exactly what you are doing.\n\nthere might be a case, and this happned to me quite some time when I\nwas working with quilt, which you don't want to automatically add all\nthe files you added on the privious commit. ie. moving defines from\nheader to .c, splitting a work to two commits.\n\nso in this case, it's ideal to just use \"git reset\" if the command\nlists files removed from the index.\n\nfor --hard option, what you want to do is to completely revert the\ncurrent state of your index file and work tree to known point.\n\nfor that, how about git-revert-script?  can we add --force option to\nthat command so that even if your working tree is dirty it reverts to\nthe specified point?\n--\n          yashi\n"},{"id":"7685","messageId":"7vpss4mbe0.fsf@assigned-by-dhcp.cox.net","threadId":"1615","inReplyTo":"87y86s2nvi.wl@mail2.atmark-techno.com","subject":"Re: [PATCH] Introduce \"reset type\" flag to \"git reset\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-24T00:22:47Z","receivedAt":"2005-08-24T00:22:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yasushi SHOJI <yashi@atmark-techno.com> writes:\n\n> for --hard option, what you want to do is to completely revert the\n> current state of your index file and work tree to known point.\n>\n> for that, how about git-revert-script?\n\n\"git revert\" is to create a commit that reverts a previous\ncommit, which I think is quite different from what we have been\ndiscussing so far.\n"},{"id":"7689","messageId":"87wtmc2mkg.wl@mail2.atmark-techno.com","threadId":"1615","inReplyTo":"7vpss4mbe0.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce \"reset type\" flag to \"git reset\"","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2005-08-24T00:41:35Z","receivedAt":"2005-08-24T00:41:35Z","isPatch":true,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"At Tue, 23 Aug 2005 17:22:47 -0700,\nJunio C Hamano wrote:\n> \n> Yasushi SHOJI <yashi@atmark-techno.com> writes:\n> \n> > for --hard option, what you want to do is to completely revert the\n> > current state of your index file and work tree to known point.\n> >\n> > for that, how about git-revert-script?\n> \n> \"git revert\" is to create a commit that reverts a previous\n> commit, which I think is quite different from what we have been\n> discussing so far.\n\nah, ok.  I was gonna suggest git-revert-script for the name but quick\ncheck showed me that we already have that script. so I just thought it\ndoes the thing.\n--\n         yashi\n"},{"id":"7714","messageId":"7vk6ibdvy1.fsf@assigned-by-dhcp.cox.net","threadId":"1615","inReplyTo":"7vacj8nw5v.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce \"reset type\" flag to \"git reset\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-24T18:35:50Z","receivedAt":"2005-08-24T18:35:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Sam Ravnborg <sam@ravnborg.org> writes:\n>\n>> But --soft, --hard looks rather confusing to me.\n>>\n>> Something like --force or --prune may be a bit more intuitive, and let\n>> default behaviour be the one you name --soft for now.\n>\n> I do not have objections to removing --mixed, but I do not find\n> --force/--prune any less confusing than --soft/--hard.  Its just\n> a terminology so once people get used to it anything would do.\n> But I agree that we need to come up with a good name for them.\n> I do not think --force/--prune is it, though.\n\nNames aside, I have a feeling that \"git reset --hard HEAD\" is\nwhat \"git checkout -f HEAD\" should have done.  As it stands, the\nlatter leaves files not in HEAD but in the previous tree behind.\n\nComments?\n"}]}