{"thread":{"id":"23964","subject":"Recovering from commit --amend in rebase --interactive","startedAt":"2010-06-01T09:27:23Z","lastAt":"2010-06-03T05:54:56Z","messageCount":8,"participants":["Peter Krefting","Boaz Harrosh","Jan Krüger","Gabriel Filion","Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"142668","messageId":"alpine.DEB.2.00.1006011022030.2352@ds9.cixit.se","threadId":"23964","inReplyTo":null,"subject":"Recovering from commit --amend in rebase --interactive","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2010-06-01T09:27:23Z","receivedAt":"2010-06-01T09:27:23Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\nI am a frequent user of rebase --interactive, and sometimes I do change a \ncommit to \"edit\", which presents me with an already committed change, which \nI can fix up, and do \"git commit --amend\" on.\n\nHowever, sometimes I get conflicts during rebase. In some cases I have \nalready seen that conflict, so rerere handles it for me. I am still dropped \nout of rebase to manually add the fixes, though.\n\nThe problem now is that is way too easy to just do a \"git commit --amend\" \nlike in the case above, and thus overwriting the previous commit \nunintentionally.\n\nIs there an easy way of working around the issue?\n\n\nLast time this happened to me, I *did* notice my mistake as I entered the \neditor, since it came up with the previous commit's message. However, as the \ncommit message file was in a good shape, I found no way to break out of the \namend. I ended up using \"git reflog\" to find out what I overwrote, then \"git \ndiff $commitid > savedpatch\" to remember what the change that I mistakenly \namended was, then \"git checkout $commitid\" and \"git apply savedpatch\" and \n\"git add\" on the changed files. What I am wondering if there is an easier \nway of recovering?\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"142672","messageId":"4C04D78A.2090103@panasas.com","threadId":"23964","inReplyTo":"alpine.DEB.2.00.1006011022030.2352@ds9.cixit.se","subject":"Re: Recovering from commit --amend in rebase --interactive","fromName":"Boaz Harrosh","fromEmail":"bharrosh@panasas.com","sentAt":"2010-06-01T09:48:58Z","receivedAt":"2010-06-01T09:48:58Z","isPatch":false,"sender":{"key":"bharrosh@panasas.com","avatar":"https://gravatar.com/avatar/347e426f8ca0409f6891ceeefd4c3c2d8769608382323057efeaa362b4c3dbf3?d=mp&s=160"},"body":"On 06/01/2010 12:27 PM, Peter Krefting wrote:\n> Hi!\n> \n> I am a frequent user of rebase --interactive, and sometimes I do change a \n> commit to \"edit\", which presents me with an already committed change, which \n> I can fix up, and do \"git commit --amend\" on.\n> \n> However, sometimes I get conflicts during rebase. In some cases I have \n> already seen that conflict, so rerere handles it for me. I am still dropped \n> out of rebase to manually add the fixes, though.\n> \n> The problem now is that is way too easy to just do a \"git commit --amend\" \n> like in the case above, and thus overwriting the previous commit \n> unintentionally.\n> \n\nThe prints are clear enough.\n\nIf stop do to \"edit\" then it prints ... you do:\ngit commit --amend\ngit rebase --continue\n\nIf stop do to merge-conflict it prints ... you do:\ngit add ... (Note no commit command)\ngit rebase --continue\n\nYou should be getting used to it after a while, I promise you\n\n> Is there an easy way of working around the issue?\n> \n> \n> Last time this happened to me, I *did* notice my mistake as I entered the \n> editor, since it came up with the previous commit's message. However, as the \n> commit message file was in a good shape, I found no way to break out of the \n> amend. \n\nWhat?!? no, why. Just empty out the message at editor and save. It will abort\nany commit and do nothing. \n(For example with kwrite, ctrl-a, delete, ctrl-s, exit)\n\nIt does not matter if the commit as entered some default text for you or\nnot. When editor is done if file is empty (or all comments) then it will\nabort and do nothing. Do not worry. The original commit is un affected.\nThe message is just extracted from the original commit put to a tmp file\nand enter into editor. (its just a commit -c after all)\n\n> I ended up using \"git reflog\" to find out what I overwrote, then \"git \n> diff $commitid > savedpatch\" to remember what the change that I mistakenly \n> amended was, then \"git checkout $commitid\" and \"git apply savedpatch\" and \n> \"git add\" on the changed files. What I am wondering if there is an easier \n> way of recovering?\n> \n\nBoaz\n"},{"id":"142674","messageId":"20100601115755.04ff4a0d@jk.gs","threadId":"23964","inReplyTo":"alpine.DEB.2.00.1006011022030.2352@ds9.cixit.se","subject":"Re: Recovering from commit --amend in rebase --interactive","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2010-06-01T09:57:55Z","receivedAt":"2010-06-01T09:57:55Z","isPatch":false,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Peter Krefting <peter@softwolves.pp.se> wrote:\n\n> Last time this happened to me, I *did* notice my mistake as I entered\n> the editor, since it came up with the previous commit's message.\n> However, as the commit message file was in a good shape, I found no\n> way to break out of the amend.\n\nIt might be easy to miss, but it's there, right in the editor:\n\n# Please enter the commit message for your changes. Lines starting\n# with '#' will be ignored, and *an empty message aborts the commit*.\n(Emphasis added)\n\nIn general, it might be helpful to warn very loudly upon doing a commit\n--amend after fixing conflicts, but an implementation would probably be\nugly and for all I know, there might be people who frequently cause\nconflicts while amending; those guys would probably be quite annoyed at\nsuch a warning.\n\n-Jan\n"},{"id":"142676","messageId":"alpine.DEB.2.00.1006011136590.2352@ds9.cixit.se","threadId":"23964","inReplyTo":"4C04D78A.2090103@panasas.com","subject":"Re: Recovering from commit --amend in rebase --interactive","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2010-06-01T10:40:09Z","receivedAt":"2010-06-01T10:40:09Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Boaz Harrosh:\n\n> The prints are clear enough.\n\nThe problem is that you stop reading them after a while. I've been using \nrebase actively for a couple of years, so I don't necessary pay much \nattention to what it says anymore.\n\nAnd besides, if I forget to do the edits in another xterm, the help text is \nusually gone by the time I need to continue anyway...\n\n> What?!? no, why. Just empty out the message at editor and save. It will \n> abort any commit and do nothing.\n\nOh. That's useful to know next time it happens :-)\n\n\nJan Krüger:\n\n> It might be easy to miss, but it's there, right in the editor:\n>\n> # Please enter the commit message for your changes. Lines starting\n> # with '#' will be ignored, and *an empty message aborts the commit*.\n> (Emphasis added)\n\nIndeed. There goes thinking you know what you do after having used the \ntools for a long time... :-)\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"142691","messageId":"4C05223A.7000204@gmail.com","threadId":"23964","inReplyTo":"alpine.DEB.2.00.1006011022030.2352@ds9.cixit.se","subject":"Re: Recovering from commit --amend in rebase --interactive","fromName":"Gabriel Filion","fromEmail":"lelutin@gmail.com","sentAt":"2010-06-01T15:07:38Z","receivedAt":"2010-06-01T15:07:38Z","isPatch":false,"sender":{"key":"lelutin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/108728?v=4"},"body":"On 2010-06-01 05:27, Peter Krefting wrote:\n> Last time this happened to me, I *did* notice my mistake as I entered\n> the editor, since it came up with the previous commit's message.\n> However, as the commit message file was in a good shape, I found no way\n> to break out of the amend. I ended up using \"git reflog\" to find out\n> what I overwrote, then \"git diff $commitid > savedpatch\" to remember\n> what the change that I mistakenly amended was, then \"git checkout\n> $commitid\" and \"git apply savedpatch\" and \"git add\" on the changed\n> files. What I am wondering if there is an easier way of recovering?\n> \n\nwhen you amend or rebase commits, the \"old\" commits are still in your\nlocal git repository as long as you don't \"git gc\" them. for this, the\nreflog can help you find the previous sha1 for the old commit. you can\nalso use \"git fsck --full\" to find out which commits were orphaned. once\nyou have the hashes, you can bring HEAD back to them.\n\nsee [1] for some simple examples of data recovery with git.\n\n[1]:http://progit.org/book/ch9-7.html#data_recovery\n\n-- \nGabriel Filion\n"},{"id":"142695","messageId":"AANLkTinNpIjirZQL1lBi3t4i6_utCIUMuXc8q2gSJvmO@mail.gmail.com","threadId":"23964","inReplyTo":"20100601115755.04ff4a0d@jk.gs","subject":"Re: Recovering from commit --amend in rebase --interactive","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-01T15:25:18Z","receivedAt":"2010-06-01T15:25:18Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Jun 1, 2010 at 09:57, Jan Krüger <jk@jk.gs> wrote:\n> Peter Krefting <peter@softwolves.pp.se> wrote:\n>\n>> Last time this happened to me, I *did* notice my mistake as I entered\n>> the editor, since it came up with the previous commit's message.\n>> However, as the commit message file was in a good shape, I found no\n>> way to break out of the amend.\n>\n> It might be easy to miss, but it's there, right in the editor:\n>\n> # Please enter the commit message for your changes. Lines starting\n> # with '#' will be ignored, and *an empty message aborts the commit*.\n> (Emphasis added)\n>\n> In general, it might be helpful to warn very loudly upon doing a commit\n> --amend after fixing conflicts, but an implementation would probably be\n> ugly and for all I know, there might be people who frequently cause\n> conflicts while amending; those guys would probably be quite annoyed at\n> such a warning.\n\nI've also introduced the error Peter describes into my history because\nI wasn't careful. That required some splitting / reflog fixes later.\n\nPerhaps the best way to solve this would be to change the content of\nCOMMIT_EDITMSG in cases like these so it gives you an explicit warning\nabout what you're about to do.\n\nWe already do this for merges, from builtin/commit.c:\n\n\t\tif (in_merge)\n\t\t\tfprintf(fp,\n\t\t\t\t\"#\\n\"\n\t\t\t\t\"# It looks like you may be committing a MERGE.\\n\"\n\t\t\t\t\"# If this is not correct, please remove the file\\n\"\n\t\t\t\t\"#\t%s\\n\"\n\t\t\t\t\"# and try again.\\n\"\n\t\t\t\t\"#\\n\",\n\t\t\t\tgit_path(\"MERGE_HEAD\"));\n\n\t\tfprintf(fp,\n\t\t\t\"\\n\"\n\t\t\t\"# Please enter the commit message for your changes.\");\n"},{"id":"142849","messageId":"7viq619fah.fsf@alter.siamese.dyndns.org","threadId":"23964","inReplyTo":"AANLkTinNpIjirZQL1lBi3t4i6_utCIUMuXc8q2gSJvmO@mail.gmail.com","subject":"Re: Recovering from commit --amend in rebase --interactive","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-06-02T23:37:58Z","receivedAt":"2010-06-02T23:37:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n>> In general, it might be helpful to warn very loudly upon doing a commit\n>> --amend after fixing conflicts, but an implementation would probably be\n>> ugly and for all I know, there might be people who frequently cause\n>> conflicts while amending; those guys would probably be quite annoyed at\n>> such a warning.\n>\n> I've also introduced the error Peter describes into my history because\n> I wasn't careful. That required some splitting / reflog fixes later.\n>\n> Perhaps the best way to solve this would be to change the content of\n> COMMIT_EDITMSG in cases like these so it gives you an explicit warning\n> about what you're about to do.\n>\n> We already do this for merges, from builtin/commit.c:\n\nVery good point.  \"Users are told when the command gives back control, is\nthe best \"rebase -i\" could do, but by definition the users are free to\nshoot themselves in the foot when given control, and \"commit --amend\" is\nthe only sensible place to give further safeguard against this issue.\n\nThanks.\n"},{"id":"142858","messageId":"AANLkTinint0-KxXr8mIK6b6Yom1oBc0Qed-Jp48wofJf@mail.gmail.com","threadId":"23964","inReplyTo":"7viq619fah.fsf@alter.siamese.dyndns.org","subject":"Re: Recovering from commit --amend in rebase --interactive","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-03T05:54:56Z","receivedAt":"2010-06-03T05:54:56Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Jun 2, 2010 at 23:37, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>>> In general, it might be helpful to warn very loudly upon doing a commit\n>>> --amend after fixing conflicts, but an implementation would probably be\n>>> ugly and for all I know, there might be people who frequently cause\n>>> conflicts while amending; those guys would probably be quite annoyed at\n>>> such a warning.\n>>\n>> I've also introduced the error Peter describes into my history because\n>> I wasn't careful. That required some splitting / reflog fixes later.\n>>\n>> Perhaps the best way to solve this would be to change the content of\n>> COMMIT_EDITMSG in cases like these so it gives you an explicit warning\n>> about what you're about to do.\n>>\n>> We already do this for merges, from builtin/commit.c:\n>\n> Very good point.  \"Users are told when the command gives back control, is\n> the best \"rebase -i\" could do, but by definition the users are free to\n> shoot themselves in the foot when given control, and \"commit --amend\" is\n> the only sensible place to give further safeguard against this issue.\n\nAs it happens I shot myself in the foot with this yesterday, here's a\nlog of what I did:\n\n    aoeu git (404M) $ git reset HEAD^\n    Unstaged changes after reset:\n    M       .gitignore\n    M       Makefile\n    M       config.mak.in\n    M       configure.ac\n    M       git.c\n    M       wt-status.c\n    aoeu git (404M) $ git st\n     M .gitignore\n     M Makefile\n     M config.mak.in\n     M configure.ac\n     M git.c\n     M wt-status.c\n    ?? gettext.c\n    ?? gettext.h\n    ?? po/\n    aoeu git (404M) $ git diff\n    aoeu git (404M) $ git show\n\n        At this point the amend message should warn me that I'm about to\n        merge stuff into the previous commit:\n\n    aoeu git (404M) $ git commit --amend\n    Waiting for Emacs...\n    [detached HEAD f9d39c1379537fb3afdfba244c61a7328dc394f2] Merge\nbranch 'maint'\n     Author: Junio C Hamano <gitster@pobox.com>\n    aoeu git (404M) $ git st\n     M wt-status.c\n    ?? gettext.c\n    ?? gettext.h\n    ?? po/\n\nActually, related to that I think this documentation section could use\nsome work:\n\n    http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_splitting_commits\n\nAt the time I was:\n\n    * Going back in my history\n    * Splitting apart some hunks to an older commit from that commit\n    * recommiting the altered commit, leaving its commit info alone\n    * Stashing the changes I'd removed into several stashes\n    * git rebase --continue and applying all the stashes to one big commit later\n\nI.e.:\n\n    git rebase -i master\n    ...\n    git reset HEAD^\n    git stash save --patch \"stash git-pull.sh\"\n    git add -u\n    git commit -c e06ef88fead1510587ff32715beaccf622dec2ce\n    git rebase --continue\n\nThe \"Commit the now-current index with whatever commit message is\nappropriate now\" part of the docs assumes that you don't want to keep\nyour old commit info around for the new rewritten commit.\n\n\nAnyway, </braindump>. This is just one example of how the rebase\nprocess could be friendlier with some minor changes, and how the\ndocumentation could be improved.\n"}]}