{"thread":{"id":"27648","subject":"Undo last commit?","startedAt":"2011-06-18T13:15:49Z","lastAt":"2012-02-11T22:29:43Z","messageCount":16,"participants":["Mike","Ben Walton","Jakub Narebski","Ramkumar Ramachandra","Jonathan Nieder","Massimo Manca","Holger Hellmuth","Junio C Hamano","Neal Kreitzinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"170198","messageId":"BANLkTinWujKYvx_fh2iBDOdMbywqzfgwUA@mail.gmail.com","threadId":"27648","inReplyTo":null,"subject":"Undo last commit?","fromName":"Mike","fromEmail":"xandrani@gmail.com","sentAt":"2011-06-18T13:15:49Z","receivedAt":"2011-06-18T13:15:49Z","isPatch":false,"sender":{"key":"xandrani@gmail.com","avatar":null},"body":"Hi fellow gitters,\n\nI have performed a 'git commit' on all 'added' files by mistake and\nnow I want to undo this commit to return to the original state. Here's\na more detailed description:\n\n\n1. I did a 'git status' and there were files which I had 'added' ready\nfor a commit. There were also some changes that had not been 'added'\nyet. See below:\n\n% git status\n# On branch master\n# Your branch is ahead of 'origin/master' by 7 commits.\n#\n# Changes to be committed:\n#   (use \"git reset HEAD <file>...\" to unstage)\n#\n#\tmodified:   cgi-bin/example1.php\n#\tmodified:   cgi-bin/example2.php\n#\tmodified:   example3.php\n#\n# Changed but not updated:\n#   (use \"git add <file>...\" to update what will be committed)\n#   (use \"git checkout -- <file>...\" to discard changes in working directory)\n#\n#\tmodified:   cgi-bin/example4.php\n#\tmodified:   example5.php\n#\n\n\n2. I accidentally did a commit for ALL files because I forgot to\nspecify the filename at the end of the commit.\ne.g. instead of 'commit -m \"commit message\" example3.php' I did\n'commit -m \"commit message\"'.\n\n3. I googled the problem and it seems everyone has a different way of\ndoing this. (Maybe git is too confusing if everyone has different\nmethods that all work slightly differently!?). Anyway I executed this\ncommand:\n\n% git commit --amend\n\nBut I aborted this by exiting my text editor.\n\n4. I then tried:\n\n% git reset --hard HEAD~1\n\n5. However now when I do a 'git status' none of the files that were\noriginal listed are there. A git status now gives this:\n\n# On branch master\n# Your branch is ahead of 'origin/master' by 7 commits.\n#\nnothing to commit (working directory clean)\n\n\nAny ideas how to rectify this issue? I presume the 'git commit\n--amend' just changes the commit message? I daren't try anything else\nmyself in case I make matters worse.\n\nMike\n"},{"id":"170199","messageId":"1308404291-sup-8978@pinkfloyd.chass.utoronto.ca","threadId":"27648","inReplyTo":"BANLkTinWujKYvx_fh2iBDOdMbywqzfgwUA@mail.gmail.com","subject":"Re: Undo last commit?","fromName":"Ben Walton","fromEmail":"bwalton@artsci.utoronto.ca","sentAt":"2011-06-18T13:43:48Z","receivedAt":"2011-06-18T13:43:48Z","isPatch":false,"sender":{"key":"bdwalton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/396061?v=4"},"body":"Excerpts from Mike's message of Sat Jun 18 09:15:49 -0400 2011:\n\nHi Mike,\n\n> 3. I googled the problem and it seems everyone has a different way of\n> doing this. (Maybe git is too confusing if everyone has different\n> methods that all work slightly differently!?). Anyway I executed this\n> command:\n> \n> % git commit --amend\n\nThis command lets you modify the last commit by either adding/removing\nchanges which you build up with git add or in the case where you've\nnot staged anything, simply edit the commit message.\n\n> % git reset --hard HEAD~1\n\nWhat you wanted was:\n\ngit reset HEAD^\nor\ngit reset HEAD~1\n\nThe --hard resets your working tree to match that commit exactly,\nthrowing away uncommitted changes.  In your case, it threw away the\nunstaged changes you'd made and the last commit.  You should be able\nto salvage your last commit by:\n\ngit reset ORIG_HEAD\n\nThe stuff that had never been git added is likely lost.  Because git\nhad never created an object for those changes, there won't be much to\nwork with.\n\nYou might inspect the output of git reflog to see if that's of any\nvalue, but I don't think it will be in your case.\n\n> Any ideas how to rectify this issue? I presume the 'git commit\n> --amend' just changes the commit message? I daren't try anything else\n> myself in case I make matters worse.\n\nAs always, take a snapshot of the .git directory before doing further\nmucking.  Maybe one of the git gurus here has ideas about the trashed\nunstaged changes...?\n\nThanks\n-Ben\n--\nBen Walton\nSystems Programmer - CHASS\nUniversity of Toronto\nC:416.407.5610 | W:416.978.4302\n"},{"id":"170201","messageId":"BANLkTinDBDkUYb=R2USV-T0=h9a3PRcATA@mail.gmail.com","threadId":"27648","inReplyTo":"BANLkTinWujKYvx_fh2iBDOdMbywqzfgwUA@mail.gmail.com","subject":"Re: Undo last commit?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-18T13:48:22Z","receivedAt":"2011-06-18T13:48:22Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Mike,\n\nMike writes:\n> I have performed a 'git commit' on all 'added' files by mistake and\n> now I want to undo this commit to return to the original state. Here's\n> a more detailed description:\n\nIn your situation, the \"correct\" answer is (arguably) 'git reset\nHEAD~1'.  This is called a mixed reset (see git-reset(1) for more).\n\n> 2. I accidentally did a commit for ALL files because I forgot to\n> specify the filename at the end of the commit.\n> e.g. instead of 'commit -m \"commit message\" example3.php' I did\n> 'commit -m \"commit message\"'.\n\nIdeally, you should only stage what you want to commit.  Isn't that\nthe reason we have a staging area?\n\n> % git commit --amend\n\nRemember that 'git commit --amend' behaves a lot like 'git commit'; it\ncommits your staged changes.  Except, instead of making a new commit,\nit adds those changes to your previous commit*.  It _additionally_\ngives you the ability to update the commit message -- when you tried\nit without any staged changes, that's what you saw.  Anyway, this is\nnot a good option in your particular case;  you'd essentially have to\nstage the inverse of all the changes you didn't intend to make in the\nprevious commit before amending the previous commit.\n\n> % git reset --hard HEAD~1\n\nOuch.  I'm sorry to have to be the one to give you the bad news; the\nchanges that you didn't commit (the \"unstaged changes\" you showed) are\nlost forever**.  This is quite a dangerous command, and must be used\nwith care.\n\n> Any ideas how to rectify this issue? I presume the 'git commit\n> --amend' just changes the commit message? I daren't try anything else\n> myself in case I make matters worse.\n\nFirst, you must find the commit you made in the reflog and cherry-pick\nit.  See git-reflog(1) and git-cherry-pick(1).  Now you've essentially\nundo the hard reset, sans your unstaged changes.  Perform a 'git reset\nHEAD~1' to move your HEAD back one step, stage the correct changes\nbefore creating new commits.  A series of commands:\n$ git reflog\n# Look for the commit you made before; let's call this b8bb3f\n$ git cherry-pick b8bb3f\n# Stage, unstage whatever you like\n$ git commit\n\n* Git never actually loses your commits unless you garbage collect, so\nyou can still find the old commit (the one that you amended to\noriginally)\n** Okay, very difficult to recover.  You'll have to find the tree\nobject corresponding to that index state.\n\n-- Ram\n"},{"id":"170200","messageId":"m31uyrutx7.fsf@localhost.localdomain","threadId":"27648","inReplyTo":"BANLkTinWujKYvx_fh2iBDOdMbywqzfgwUA@mail.gmail.com","subject":"Re: Undo last commit?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-06-18T13:54:50Z","receivedAt":"2011-06-18T13:54:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Mike <xandrani@gmail.com> writes:\n\n> Hi fellow gitters,\n> \n> I have performed a 'git commit' on all 'added' files by mistake and\n> now I want to undo this commit to return to the original state. Here's\n> a more detailed description:\n> \n> \n> 1. I did a 'git status' and there were files which I had 'added' ready\n> for a commit. There were also some changes that had not been 'added'\n> yet. See below:\n> \n> % git status\n> # On branch master\n> # Your branch is ahead of 'origin/master' by 7 commits.\n> #\n> # Changes to be committed:\n> #   (use \"git reset HEAD <file>...\" to unstage)\n> #\n> #\tmodified:   cgi-bin/example1.php\n> #\tmodified:   cgi-bin/example2.php\n> #\tmodified:   example3.php\n> #\n> # Changed but not updated:\n> #   (use \"git add <file>...\" to update what will be committed)\n> #   (use \"git checkout -- <file>...\" to discard changes in working directory)\n> #\n> #\tmodified:   cgi-bin/example4.php\n> #\tmodified:   example5.php\n> #\n> \n> \n> 2. I accidentally did a commit for ALL files because I forgot to\n> specify the filename at the end of the commit.\n> e.g. instead of 'commit -m \"commit message\" example3.php' I did\n> 'commit -m \"commit message\"'.\n\nYou committed all staged changes (i.e. only those on \"Changes to be\ncommitted\" list), not all changes; for that you would need to use '-a'\noption to git commit.\n\nBTW. why are you using '-m' option?\n \n> 3. I googled the problem and it seems everyone has a different way of\n> doing this. (Maybe git is too confusing if everyone has different\n> methods that all work slightly differently!?). Anyway I executed this\n> command:\n> \n> % git commit --amend\n\nYou could simply use\n\n  % git commit --amend -m \"commit message\" example3.php\n\nThe `--amend` just means to fix (redo) last commit.\n\n> But I aborted this by exiting my text editor.\n\nO.K.\n\n> 4. I then tried:\n> \n> % git reset --hard HEAD~1\n\nErrr... here you screwed up.  This reset state of you working area to\nthe state at last commit, removing all your changes to tracked files.\n\n> 5. However now when I do a 'git status' none of the files that were\n> original listed are there. A git status now gives this:\n> \n> # On branch master\n> # Your branch is ahead of 'origin/master' by 7 commits.\n> #\n> nothing to commit (working directory clean)\n> \n> \n> Any ideas how to rectify this issue? I presume the 'git commit\n> --amend' just changes the commit message? I daren't try anything else\n> myself in case I make matters worse.\n\nYou lost your changes to files on \"Changed but not updated\" list,\ni.e. cgi-bin/example4.php and example5.php.\n\nWhat you can do is go back to your last commit (the errorneous one) by\nusing\n\n  $ git reset --keep HEAD@{1}\n\nWhich means reset to last state (before 'git reset --hard HEAD~1'; you\ncan check it with \"git reflog\" or \"git log -g\"), keeping your local\nchanges (if you used '--keep' not '--hard' then you wouldn't loose\nyour changes).\n\nThen redo this commit like you wanted to\n\n  $ git commit --amend -m \"commit message\" example3.php\n\nOr better\n\n  $ git commit --amend -v example3.php\n\nTo check if you are committing correct changes.\n\n...................\n\nAlternatively check out state of example3.php from last made commit:\n\n  $ git checkout HEAD@{1} -- example3.php\n\nDo your commit\n\n  $ git commit -m \"commit message\" example3.php\n\nGet state of other files that you accidentally comitted from next to\nlast state of HEAD:\n\n  $ git checkout HEAD@{2} -- cgi-bin/example1.php cgi-bin/example2.php\n\nUnfortunately changes to cgi-bin/example4.php and example5.php are\nlost.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"170224","messageId":"20110619003718.GA5628@elie","threadId":"27648","inReplyTo":"m31uyrutx7.fsf@localhost.localdomain","subject":"Re: Undo last commit?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-06-19T00:37:18Z","receivedAt":"2011-06-19T00:37:18Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJakub Narebski wrote:\n> Mike <xandrani@gmail.com> writes:\n\n>> % git reset --hard HEAD~1\n>\n> Errr... here you screwed up.  This reset state of you working area to\n> the state at last commit, removing all your changes to tracked files.\n\nOr rather, here we screwed up.  Jakub and others gave some useful\nadvice about how to recover, so let's consider how the UI or\ndocumentation could be improved to prevent it from happening again.\n\n* In this example if I understand correctly then the index contained\n  some useful information, perhaps about a larger commit intended for\n  later.  To preserve that, you could have used\n\n\tgit reset --soft HEAD~1\n\n  which would _just_ undo the effect of \"git commit\", leaving the index\n  and worktree alone.\n\n* Another situation that comes up from time to time is making a change\n  that just turned out to be a bad idea.  After commiting it, you might\n  want to discard the erroneous change, like so:\n\n\tgit reset --keep HEAD~1\n\n  The \"--keep\" option uses some safeguards to make sure that only the\n  committed change gets discarded, instead of clobbering local changes\n  at the same time.\n\n* In the early days of git, the \"--keep\" option did not exist.  So a lot\n  of old documentation recommends to do\n\n\tgit reset --hard HEAD~1\n\n  which is the same if you don't have any local changes.\n\nIt would be useful to fix such documentation by adding a few words\nabout local changes.  Recently Duy wrote a patch to improve \"reset -h\"\noutput in that vein, but discussion drifted off:\n\n http://thread.gmane.org/gmane.comp.version-control.git/170266\n\nI also sent a couple of documentation patches and then dropped the\nball:\n\n http://thread.gmane.org/gmane.comp.version-control.git/165358\n http://thread.gmane.org/gmane.comp.version-control.git/160319\n\nIf someone wants to pick any of these up and run with it, I wouldn't\nmind (hey, I'd be happy).\n\nThanks for a useful example.\nJonathan\n"},{"id":"170229","messageId":"201106191237.55825.jnareb@gmail.com","threadId":"27648","inReplyTo":"20110619003718.GA5628@elie","subject":"Re: Undo last commit?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-06-19T10:37:54Z","receivedAt":"2011-06-19T10:37:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 19 Jun 2011, Jonathan Nieder wrote:\n> Jakub Narebski wrote:\n> > Mike <xandrani@gmail.com> writes:\n> \n> > > % git reset --hard HEAD~1\n> >\n> > Errr... here you screwed up.  This reset state of you working area to\n> > the state at last commit, removing all your changes to tracked files.\n> \n> Or rather, here we screwed up.  Jakub and others gave some useful\n> advice about how to recover, so let's consider how the UI or\n> documentation could be improved to prevent it from happening again.\n> \n> * In this example if I understand correctly then the index contained\n>   some useful information, perhaps about a larger commit intended for\n>   later.  To preserve that, you could have used\n> \n> \tgit reset --soft HEAD~1\n> \n>   which would _just_ undo the effect of \"git commit\", leaving the index\n>   and worktree alone.\n\nAnother issue is that Mike haven't realized that `--amend' option can be\nused *in combination* with other \"git commit\" options, which means that\nthe solution to his problem was using \"git commit\" as it should have\nbeen done, but with '--amend' added.\n \nI'm not sure if git documentation talks about 'git reset --soft HEAD^',\nand when to use it; from what I remember it encourages use of \n'git commit --amend' instead (which was I guess most often used reason\nof using soft reset before there was '--amend').\n\n> * Another situation that comes up from time to time is making a change\n>   that just turned out to be a bad idea.  After commiting it, you might\n>   want to discard the erroneous change, like so:\n> \n> \tgit reset --keep HEAD~1\n> \n>   The \"--keep\" option uses some safeguards to make sure that only the\n>   committed change gets discarded, instead of clobbering local changes\n>   at the same time.\n>\n> * In the early days of git, the \"--keep\" option did not exist.  So a lot\n>   of old documentation recommends to do\n> \n> \tgit reset --hard HEAD~1\n> \n>   which is the same if you don't have any local changes.\n\nYes, it would be good idea to examine git documentation (tutorials,\nuser's manual, manpages, perhaps \"Git Community Book\" and \"Pro Git\"\ntoo) to encourage use of new safer options of hard reset, namely\n'--keep' and '--merge' instead of '--hard'.\n \n-- \nJakub Narebski\nPoland\n"},{"id":"170294","messageId":"4DFF382A.5030206@micronengineering.it","threadId":"27648","inReplyTo":"201106191237.55825.jnareb@gmail.com","subject":"Re: Undo last commit?","fromName":"Massimo Manca","fromEmail":"massimo.manca@micronengineering.it","sentAt":"2011-06-20T12:08:10Z","receivedAt":"2011-06-20T12:08:10Z","isPatch":false,"sender":{"key":"massimo.manca@micronengineering.it","avatar":"https://gravatar.com/avatar/1c2a993a173142d1f7fe53dcf07a0769b89feebd2e9f6d618d9d13e2a7391a94?d=mp&s=160"},"body":"Hello,\nI several times made the mistake of a wrong commit also if generally the\nerror born for a wrong add expecially:\n\ngit add . in a directory with some files that haven't to be managed by git.\n\nSo, as wrote in some emails here, if I wrote something like:\ngit commit -m \"Added file.c\" -a\n\nI tryed to solve with:\ngit commit --amend -m \"Added file.c\" -a\n\nhoping to have a status like before the commit and then sending:\ngit reset .\n\nhoping to have a status like that before the wrong add.\nBut this is not what git status say so, my solution to solve commi\nproblems is ALWAYS:\n\ngit reset --soft HEAD^\n\nthat for my point of view works better then all others permitting to\nredo last add and commit to solve not only a -m problem but also a wrong\ngit add command.\n\nIl 19/06/2011 12.37, Jakub Narebski ha scritto:\n> On Sun, 19 Jun 2011, Jonathan Nieder wrote:\n>> Jakub Narebski wrote:\n>>> Mike <xandrani@gmail.com> writes:\n>>>> % git reset --hard HEAD~1\n>>> Errr... here you screwed up.  This reset state of you working area to\n>>> the state at last commit, removing all your changes to tracked files.\n>> Or rather, here we screwed up.  Jakub and others gave some useful\n>> advice about how to recover, so let's consider how the UI or\n>> documentation could be improved to prevent it from happening again.\n>>\n>> * In this example if I understand correctly then the index contained\n>>   some useful information, perhaps about a larger commit intended for\n>>   later.  To preserve that, you could have used\n>>\n>> \tgit reset --soft HEAD~1\n>>\n>>   which would _just_ undo the effect of \"git commit\", leaving the index\n>>   and worktree alone.\n> Another issue is that Mike haven't realized that `--amend' option can be\n> used *in combination* with other \"git commit\" options, which means that\n> the solution to his problem was using \"git commit\" as it should have\n> been done, but with '--amend' added.\n>  \n> I'm not sure if git documentation talks about 'git reset --soft HEAD^',\n> and when to use it; from what I remember it encourages use of \n> 'git commit --amend' instead (which was I guess most often used reason\n> of using soft reset before there was '--amend').\n>\n>> * Another situation that comes up from time to time is making a change\n>>   that just turned out to be a bad idea.  After commiting it, you might\n>>   want to discard the erroneous change, like so:\n>>\n>> \tgit reset --keep HEAD~1\n>>\n>>   The \"--keep\" option uses some safeguards to make sure that only the\n>>   committed change gets discarded, instead of clobbering local changes\n>>   at the same time.\n>>\n>> * In the early days of git, the \"--keep\" option did not exist.  So a lot\n>>   of old documentation recommends to do\n>>\n>> \tgit reset --hard HEAD~1\n>>\n>>   which is the same if you don't have any local changes.\n> Yes, it would be good idea to examine git documentation (tutorials,\n> user's manual, manpages, perhaps \"Git Community Book\" and \"Pro Git\"\n> too) to encourage use of new safer options of hard reset, namely\n> '--keep' and '--merge' instead of '--hard'.\n>  \n\n\n\nbegin:vcard\nfn:Massimo Manca\nn:Manca;Massimo\norg:Micron Engineering di Massimo Manca\nadr:;;via della Ferriera, 48;Pordenone;PN;33170;ITALIA\nemail;internet:massimo.manca@micronengineering.it\ntel;work:+39 0434 1856131\ntel;fax:+39 0434 1851032 / 178 273 3543\ntel;cell:+39 349 4504979\nurl:http://www.micronengineering.it\nversion:2.1\nend:vcard\n\n"},{"id":"170624","messageId":"4E09DDAE.30801@ira.uka.de","threadId":"27648","inReplyTo":"4DFF382A.5030206@micronengineering.it","subject":"Re: Undo last commit?","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2011-06-28T13:57:02Z","receivedAt":"2011-06-28T13:57:02Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Let me play devils advocate:\nWouldn't it be nice to have a command 'git uncommit' (in core git) that \nwould be an alias to \"git reset --keep HEAD^\" ? And if not already done, \nit should hint at \"git reset --soft HEAD^\" in case of failure because of \nconflicts.\n\nIt would be a nice companion to the not-yet-realized \"git unadd\" ;-)\n\nHolger.\n\n\nOn 20.06.2011 14:08, Massimo Manca wrote:\n> Hello,\n> I several times made the mistake of a wrong commit also if generally the\n> error born for a wrong add expecially:\n>\n> git add . in a directory with some files that haven't to be managed by git.\n>\n> So, as wrote in some emails here, if I wrote something like:\n> git commit -m \"Added file.c\" -a\n>\n> I tryed to solve with:\n> git commit --amend -m \"Added file.c\" -a\n>\n> hoping to have a status like before the commit and then sending:\n> git reset .\n>\n> hoping to have a status like that before the wrong add.\n> But this is not what git status say so, my solution to solve commi\n> problems is ALWAYS:\n>\n> git reset --soft HEAD^\n>\n> that for my point of view works better then all others permitting to\n> redo last add and commit to solve not only a -m problem but also a wrong\n> git add command.\n>\n> Il 19/06/2011 12.37, Jakub Narebski ha scritto:\n>> On Sun, 19 Jun 2011, Jonathan Nieder wrote:\n>>> Jakub Narebski wrote:\n>>>> Mike<xandrani@gmail.com>  writes:\n>>>>> % git reset --hard HEAD~1\n>>>> Errr... here you screwed up.  This reset state of you working area to\n>>>> the state at last commit, removing all your changes to tracked files.\n>>> Or rather, here we screwed up.  Jakub and others gave some useful\n>>> advice about how to recover, so let's consider how the UI or\n>>> documentation could be improved to prevent it from happening again.\n>>>\n>>> * In this example if I understand correctly then the index contained\n>>>    some useful information, perhaps about a larger commit intended for\n>>>    later.  To preserve that, you could have used\n>>>\n>>> \tgit reset --soft HEAD~1\n>>>\n>>>    which would _just_ undo the effect of \"git commit\", leaving the index\n>>>    and worktree alone.\n>> Another issue is that Mike haven't realized that `--amend' option can be\n>> used *in combination* with other \"git commit\" options, which means that\n>> the solution to his problem was using \"git commit\" as it should have\n>> been done, but with '--amend' added.\n>>\n>> I'm not sure if git documentation talks about 'git reset --soft HEAD^',\n>> and when to use it; from what I remember it encourages use of\n>> 'git commit --amend' instead (which was I guess most often used reason\n>> of using soft reset before there was '--amend').\n>>\n>>> * Another situation that comes up from time to time is making a change\n>>>    that just turned out to be a bad idea.  After commiting it, you might\n>>>    want to discard the erroneous change, like so:\n>>>\n>>> \tgit reset --keep HEAD~1\n>>>\n>>>    The \"--keep\" option uses some safeguards to make sure that only the\n>>>    committed change gets discarded, instead of clobbering local changes\n>>>    at the same time.\n>>>\n>>> * In the early days of git, the \"--keep\" option did not exist.  So a lot\n>>>    of old documentation recommends to do\n>>>\n>>> \tgit reset --hard HEAD~1\n>>>\n>>>    which is the same if you don't have any local changes.\n>> Yes, it would be good idea to examine git documentation (tutorials,\n>> user's manual, manpages, perhaps \"Git Community Book\" and \"Pro Git\"\n>> too) to encourage use of new safer options of hard reset, namely\n>> '--keep' and '--merge' instead of '--hard'.\n>>\n>\n"},{"id":"170625","messageId":"BANLkTimZN4swfY13zMjkCbAc9UsGSix02Q@mail.gmail.com","threadId":"27648","inReplyTo":"4E09DDAE.30801@ira.uka.de","subject":"Re: Undo last commit?","fromName":"Mike","fromEmail":"xandrani@gmail.com","sentAt":"2011-06-28T14:31:23Z","receivedAt":"2011-06-28T14:31:23Z","isPatch":false,"sender":{"key":"xandrani@gmail.com","avatar":null},"body":"I've created a 'wrapper' for git which stops me from making dumb\nmistakes, it is working really well so far. I will add your ideas to\nit... thanks!\n\nI do think that git needs polishing in this way. It was designed by a\nvery intelligent programmer... however they can sometimes be the worst\nat user interface design. I think a lot of people are missing out on\nhow great git is because of the learning curve, and also the slightly\nodd naming conventions.\n\n\"git reset --soft HEAD^\" can't be picked up that quickly by a\nbeginner, but git uncommit would be obvious! So I have to agree with\nHolger. Good design makes something intuitive. I have used DVD\nrecorder / players that are so badly designed that I needed to read\nthe instruction manual. Something complicated can be designed to such\na degree that people rarely have to read a manual, and they can pick\nit up really quickly because it's obvious. If you disagree then you\nmight need to learn something about good design because what I say\nisn't opinion it's a fact. Flame away :)\n\nApologies for stereotyping!\n\nOn 28 June 2011 14:57, Holger Hellmuth <hellmuth@ira.uka.de> wrote:\n> Let me play devils advocate:\n> Wouldn't it be nice to have a command 'git uncommit' (in core git) that\n> would be an alias to \"git reset --keep HEAD^\" ? And if not already done, it\n> should hint at \"git reset --soft HEAD^\" in case of failure because of\n> conflicts.\n>\n> It would be a nice companion to the not-yet-realized \"git unadd\" ;-)\n>\n> Holger.\n>\n>\n> On 20.06.2011 14:08, Massimo Manca wrote:\n>>\n>> Hello,\n>> I several times made the mistake of a wrong commit also if generally the\n>> error born for a wrong add expecially:\n>>\n>> git add . in a directory with some files that haven't to be managed by\n>> git.\n>>\n>> So, as wrote in some emails here, if I wrote something like:\n>> git commit -m \"Added file.c\" -a\n>>\n>> I tryed to solve with:\n>> git commit --amend -m \"Added file.c\" -a\n>>\n>> hoping to have a status like before the commit and then sending:\n>> git reset .\n>>\n>> hoping to have a status like that before the wrong add.\n>> But this is not what git status say so, my solution to solve commi\n>> problems is ALWAYS:\n>>\n>> git reset --soft HEAD^\n>>\n>> that for my point of view works better then all others permitting to\n>> redo last add and commit to solve not only a -m problem but also a wrong\n>> git add command.\n>>\n>> Il 19/06/2011 12.37, Jakub Narebski ha scritto:\n>>>\n>>> On Sun, 19 Jun 2011, Jonathan Nieder wrote:\n>>>>\n>>>> Jakub Narebski wrote:\n>>>>>\n>>>>> Mike<xandrani@gmail.com>  writes:\n>>>>>>\n>>>>>> % git reset --hard HEAD~1\n>>>>>\n>>>>> Errr... here you screwed up.  This reset state of you working area to\n>>>>> the state at last commit, removing all your changes to tracked files.\n>>>>\n>>>> Or rather, here we screwed up.  Jakub and others gave some useful\n>>>> advice about how to recover, so let's consider how the UI or\n>>>> documentation could be improved to prevent it from happening again.\n>>>>\n>>>> * In this example if I understand correctly then the index contained\n>>>>   some useful information, perhaps about a larger commit intended for\n>>>>   later.  To preserve that, you could have used\n>>>>\n>>>>        git reset --soft HEAD~1\n>>>>\n>>>>   which would _just_ undo the effect of \"git commit\", leaving the index\n>>>>   and worktree alone.\n>>>\n>>> Another issue is that Mike haven't realized that `--amend' option can be\n>>> used *in combination* with other \"git commit\" options, which means that\n>>> the solution to his problem was using \"git commit\" as it should have\n>>> been done, but with '--amend' added.\n>>>\n>>> I'm not sure if git documentation talks about 'git reset --soft HEAD^',\n>>> and when to use it; from what I remember it encourages use of\n>>> 'git commit --amend' instead (which was I guess most often used reason\n>>> of using soft reset before there was '--amend').\n>>>\n>>>> * Another situation that comes up from time to time is making a change\n>>>>   that just turned out to be a bad idea.  After commiting it, you might\n>>>>   want to discard the erroneous change, like so:\n>>>>\n>>>>        git reset --keep HEAD~1\n>>>>\n>>>>   The \"--keep\" option uses some safeguards to make sure that only the\n>>>>   committed change gets discarded, instead of clobbering local changes\n>>>>   at the same time.\n>>>>\n>>>> * In the early days of git, the \"--keep\" option did not exist.  So a lot\n>>>>   of old documentation recommends to do\n>>>>\n>>>>        git reset --hard HEAD~1\n>>>>\n>>>>   which is the same if you don't have any local changes.\n>>>\n>>> Yes, it would be good idea to examine git documentation (tutorials,\n>>> user's manual, manpages, perhaps \"Git Community Book\" and \"Pro Git\"\n>>> too) to encourage use of new safer options of hard reset, namely\n>>> '--keep' and '--merge' instead of '--hard'.\n>>>\n>>\n>\n>\n"},{"id":"170695","messageId":"BANLkTim459-Jx2R9GpBdkck7PMAEbamJeA@mail.gmail.com","threadId":"27648","inReplyTo":"BANLkTimZN4swfY13zMjkCbAc9UsGSix02Q@mail.gmail.com","subject":"Re: Undo last commit?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-30T04:50:40Z","receivedAt":"2011-06-30T04:50:40Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Mike,\n\nMike writes:\n> I do think that git needs polishing in this way. It was designed by a\n> very intelligent programmer... however they can sometimes be the worst\n> at user interface design. I think a lot of people are missing out on\n> how great git is because of the learning curve, and also the slightly\n> odd naming conventions.\n>\n> \"git reset --soft HEAD^\" can't be picked up that quickly by a\n> beginner, but git uncommit would be obvious! So I have to agree with\n> Holger. Good design makes something intuitive. I have used DVD\n> recorder / players that are so badly designed that I needed to read\n> the instruction manual. Something complicated can be designed to such\n> a degree that people rarely have to read a manual, and they can pick\n> it up really quickly because it's obvious. If you disagree then you\n> might need to learn something about good design because what I say\n> isn't opinion it's a fact. Flame away :)\n\nI completely agree with you.  Git's user interface can certainly be\nimproved -- we have had many many discussions on this topic (like\n{1]).  Unfortunately, the way to go about doing it is not to implement\nevery little suggestion and introduce more inconsistencies;  Git is\nvery complex, and changing one little thing requires us to think about\nhow it'll affect everything else.  Yes, it does seem like a daunting\ntask, but the interface IS improving slowly and steadily.  You can\nhelp by thinking about how a certain new feature will interact with\nevery component of Git, and participating in UI discussions.\n\n-- Ram\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/175061\n"},{"id":"170715","messageId":"7vfwmrqlc3.fsf@alter.siamese.dyndns.org","threadId":"27648","inReplyTo":"BANLkTimZN4swfY13zMjkCbAc9UsGSix02Q@mail.gmail.com","subject":"Re: Undo last commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-30T17:29:32Z","receivedAt":"2011-06-30T17:29:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike <xandrani@gmail.com> writes:\n\n> \"git reset --soft HEAD^\" can't be picked up that quickly by a\n> beginner, but git uncommit would be obvious!\n\nSo would \"git commit --amend\", before which \"reset --soft HEAD^\" was the\nonly way to prepare doing it, but after which \"reset --soft HEAD^\" more or\nless outlived its usefulness for that particular use case.\n"},{"id":"170721","messageId":"20110630183830.GA4294@elie","threadId":"27648","inReplyTo":"BANLkTim459-Jx2R9GpBdkck7PMAEbamJeA@mail.gmail.com","subject":"Re: Undo last commit?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-06-30T18:38:30Z","receivedAt":"2011-06-30T18:38:30Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ramkumar Ramachandra wrote:\n> Mike writes:\n\n>> I do think that git needs polishing in this way. It was designed by a\n>> very intelligent programmer... however they can sometimes be the worst\n>> at user interface design.\n[...]\n> Git is\n> very complex, and changing one little thing requires us to think about\n> how it'll affect everything else.\n\nOh, dear.  No, I don't think these things are true at all (or at least I\nhope we act so as to make them not true).  In its history, just like Jakub\nlikes to remind us now and then, git _evolved_.  To make it better, it\nshould be sufficient to do three things:\n\n 1. When there is a small, obvious change that can make something\n    better, do it.\n\n 2. When there is a small, obvious change that can make git simpler\n    and more flexible (so other changes can become small and obvious),\n    do it.\n\n 3. When there is a big, possibly advantageous change, try it out\n    locally (e.g., on a branch).  If it turns out to work well, use it.\n\nWhile it is always nice to see people thinking carefully, none of the\nabove necessarily requires thinking about all of git at once.  In\nparticular, (2) suggests that any feature leading a well informed\nperson to say \"Git is very complex\" is a bug.\n"},{"id":"170727","messageId":"BANLkTinLMez=nv4fTcFWtqRb01231sMT1g@mail.gmail.com","threadId":"27648","inReplyTo":"20110630183830.GA4294@elie","subject":"Re: Undo last commit?","fromName":"Mike","fromEmail":"xandrani@gmail.com","sentAt":"2011-06-30T19:48:34Z","receivedAt":"2011-06-30T19:48:34Z","isPatch":false,"sender":{"key":"xandrani@gmail.com","avatar":null},"body":"You have a great attitude to design (especially that of software).\n\nI love it when people take feedback as a positive thing, and not as a\ncriticism! :)\n\n2011/6/30 Jonathan Nieder <jrnieder@gmail.com>:\n> Ramkumar Ramachandra wrote:\n>> Mike writes:\n>\n>>> I do think that git needs polishing in this way. It was designed by a\n>>> very intelligent programmer... however they can sometimes be the worst\n>>> at user interface design.\n> [...]\n>> Git is\n>> very complex, and changing one little thing requires us to think about\n>> how it'll affect everything else.\n>\n> Oh, dear.  No, I don't think these things are true at all (or at least I\n> hope we act so as to make them not true).  In its history, just like Jakub\n> likes to remind us now and then, git _evolved_.  To make it better, it\n> should be sufficient to do three things:\n>\n>  1. When there is a small, obvious change that can make something\n>    better, do it.\n>\n>  2. When there is a small, obvious change that can make git simpler\n>    and more flexible (so other changes can become small and obvious),\n>    do it.\n>\n>  3. When there is a big, possibly advantageous change, try it out\n>    locally (e.g., on a branch).  If it turns out to work well, use it.\n>\n> While it is always nice to see people thinking carefully, none of the\n> above necessarily requires thinking about all of git at once.  In\n> particular, (2) suggests that any feature leading a well informed\n> person to say \"Git is very complex\" is a bug.\n>\n"},{"id":"184465","messageId":"4F36B147.3070501@gmail.com","threadId":"27648","inReplyTo":"4E09DDAE.30801@ira.uka.de","subject":"Re: Undo last commit?","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-02-11T18:19:51Z","receivedAt":"2012-02-11T18:19:51Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 6/28/2011 8:57 AM, Holger Hellmuth wrote:\n>\n> It would be a nice companion to the not-yet-realized \"git unadd\" ;-)\n>\nor perhaps \"git unstage\"...\n\nv/r,\nneal\n"},{"id":"184476","messageId":"201202112307.10528.jnareb@gmail.com","threadId":"27648","inReplyTo":"CAHK-92oMc62O0S8Bxt6+uxobE+kg5wOeRDoOsHWvvenXaXmZGQ@mail.gmail.com","subject":"Re: Undo last commit?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-11T22:07:09Z","receivedAt":"2012-02-11T22:07:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Please do not top-post, and do not remove git mailing list from Cc.\nSorry for double posting; forgot to re-add git@vger.kernel.org\n\nOn Sat, 11 Feb 2012, Mike ??? wrote:\n> 2012/2/11 Neal Kreitzinger <nkreitzinger@gmail.com>\n> > On 6/28/2011 8:57 AM, Holger Hellmuth wrote:\n> > >\n> > > It would be a nice companion to the not-yet-realized \"git unadd\" ;-)\n> >\n> > or perhaps \"git unstage\"...\n>\n> If lot's of people have the same problem then it IS a design flaw. If\n> something is designed well and genuinely intuitive then they just work.\n> Think iPhone, iPod, some DVD players and other well designed user\n> interfaces. The same goes for command line tools... the options should have\n> names that don't have any ambiguity.\n> \nMany of problems with git user interface have their source from the fact\nthat git, including its interface, was evolved rather than created using\nbig-design-upfront workflow.  And it _had_ to be evolved, as there was not\nmuch of prior art (well, not good prior art) in the area of DVCS.\n\nBesides, as they say:\n\n  The only \"intuitive\" interface is the nipple. After that it's all learned.\n\n                                                             -- Bruce Ediger\n\n> Techie guys almost always blame the users, this is a very bad attitude. For\n> example I've met so many techies that THINK they can design websites...\n> err... they can't. They CAN program sure, but they CAN'T design the user\n> experience properly as that is not their expertise. Just as we wouldn't\n> expect a graphic designer or user interface specialist to do the coding.\n> \nThere is also problem in that you need to know git well to _code_ interface;\nand when you know git well you don't notice no longer the problems that you\nhad as a newbie.\n\nOn the other hand new git users sometimes have problems distinguishing\nbetween accidental complexity of bad UI design, and essential complexity\nof a powerfull and flexible tool.\n\n[...]\n\nSo, Mike, will you bitch or will you try to help?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"184477","messageId":"20120211222943.GA2719@burratino","threadId":"27648","inReplyTo":"201202112307.10528.jnareb@gmail.com","subject":"Re: Undo last commit?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-11T22:29:43Z","receivedAt":"2012-02-11T22:29:43Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJakub Narebski wrote:\n\n> So, Mike, will you bitch or will you try to help?\n\nI sent a message (not to the git list by accident, sorry) that made\nthe same mistake, but I think I was misdiagnosing.\n\nI suspect Mike wanted to invite us to take a closer look at the story\nin [1] and learn what can be learned from it.  (For example, may be an\nerror message or some documentation needs to be improved, or maybe new\nenhancements like \"git checkout -B master HEAD^\" would have helped.)\n\nUnfortunately the message [1] is not very focused, making it hard to\nlearn from.  So my advice to Mike would be to try again, and to\nclearly explain what problem he was trying to solve and when git\nfailed him (either by a command producing a different effect than\nexpected or the appropriate command to carry out some action being\nhard to find).\n\nJonathan\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/175968\n"}]}