{"thread":{"id":"27219","subject":"git symbolic-ref vs. reflog (vs. rebase)","startedAt":"2011-04-29T15:03:52Z","lastAt":"2011-05-27T20:16:14Z","messageCount":11,"participants":["Csaba Henk","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"166738","messageId":"ipek0o$l0v$1@dough.gmane.org","threadId":"27219","inReplyTo":null,"subject":"git symbolic-ref vs. reflog (vs. rebase)","fromName":"Csaba Henk","fromEmail":"csaba@lowlife.hu","sentAt":"2011-04-29T15:03:52Z","receivedAt":"2011-04-29T15:03:52Z","isPatch":false,"sender":{"key":"csaba@gluster.com","avatar":"https://avatars.githubusercontent.com/u/43937?v=4"},"body":"\"git symbolic-ref\" is a dangerous command in the sense that it can\nchange your HEAD position without updating the reflog. Is it\nintended behaviour?\n\nI found now a case where this feature causes strange behavior.\nIt seems to me that either behaviour of git symbolic-ref, or the way\nit is used should be changed, but I'm not sure which of these\nwould be the right solution.\n\nIf I'm at a detached HEAD and I do a rebase onto it, from which then\nI step back with \"git rebase --abort\", then I seem to lose references\nto the HEAD before rebase, as git reflog won't show it anymore.\n\nThis is because of two factors:\n\n- unlike a rebase onto a branch-referred head, we don't get an\n additional reflog entry for moving to the starting position\n of the rebase (ie. we don't actually changes HEAD, nevertheless\n in the branchy case a dummy reflog entry is made for HEAD);\n\n- upon aborting the rebase, a call is done to \"git symbolic-ref\"\n in the aforementioned unsafe way, ie. it changes HEAD but\n does not update reflog.\n\nThe phenomenon is illustrated by the script below. Usage:\n\n- fist arg is the dir where the script will run (should\n not exist at invocation, script creates it).\n\n- optional second arg is a branchname, if you give it, you'll\n see the branchy case, else you get the rebase-onto-detached\n case\n\nObserve the following: \n\n- in both of branchy and detached cases, one reflog entry for\n the starting HEAD disappears from reflog output, but in the\n branchy case there are two of them before \"rebase --abort\"\n so you don't lose the reference;\n\n- \"rebase --abort\" does not change the reflog file, but\n the reflog command's output changes, as it shows the actual HEAD\n as HEAD{0}, regardless of the last log entry.\n\nCsaba\n\n * * *\n\nbash> cat gtr.sh\n#!/bin/bash -e\n\nGIT=${GIT:-git}\n\nif !([ $# -eq 1 ] || [ $# -eq 2 ]) || [ \"$1\" = -h ]; then\n echo usage: `basename $0` scratchdir [branchname]\nfi\n\nif ! [ -z $2 ]; then\n branch=$2\n bropt=-b\nfi\n\nmkdir \"$1\"\ncd \"$1\"\n\n{\n$GIT init\n\necho master > file\n$GIT add file\n$GIT commit -m Master.\n\n$GIT checkout -b topic\necho topic > file\n$GIT commit -am Topic.\n\n$GIT checkout $bropt $branch master~0\necho detached > file\n$GIT commit -am 'Rebase base'.\n} &>/dev/null\n\necho\n$GIT log --all --graph --decorate --pretty=oneline\necho\n\nset -x\n\n$GIT hash-object .git/logs/HEAD\n$GIT rebase HEAD topic || :\n$GIT hash-object .git/logs/HEAD\n$GIT reflog\n# ruby is used to compactify the logfile,\n# if you don't have ruby, comment out\n# the filtering part.\ncat .git/logs/HEAD | ruby -ane 'puts $F.map{|x| x[0..(x =~ /:$/ ? -1 : 7)] }.join(\" \")'\n$GIT rebase --abort\n$GIT hash-object .git/logs/HEAD\n$GIT reflog\n\nbash> ./gtr.sh testdir\n\n* 27a1300e35857be6357adaf6759eb8ce0818d37b (topic) Topic.\n| * 5d4be82c08bf6effc906a37419220ca428834844 (HEAD) Rebase base.\n|/\n* 6fa006d134be4d986e1a680cac4eddd61494164a (master) Master.\n\n+ git hash-object .git/logs/HEAD\ncd15f363cf16ea3e03f5177b502de8ce3543ff21\n+ git rebase HEAD topic\nFirst, rewinding head to replay your work on top of it...\nApplying: Topic.\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nAuto-merging file\nCONFLICT (content): Merge conflict in file\nFailed to merge in the changes.\nPatch failed at 0001 Topic.\n\nWhen you have resolved this problem run \"git rebase --continue\".\nIf you would prefer to skip this patch, instead run \"git rebase --skip\".\nTo restore the original branch and stop rebasing run \"git rebase --abort\".\n\n+ :\n+ git hash-object .git/logs/HEAD\ncd15f363cf16ea3e03f5177b502de8ce3543ff21\n+ git reflog\n5d4be82 HEAD@{0}: commit: Rebase base.\n6fa006d HEAD@{1}: checkout: moving from topic to master~0\n27a1300 HEAD@{2}: commit: Topic.\n6fa006d HEAD@{3}: checkout: moving from master to topic\n6fa006d HEAD@{4}: commit (initial): Master.\n+ cat .git/logs/HEAD\n+ ruby -ane 'puts $F.map{|x| x[0..(x =~ /:$/ ? -1 : 7)] }.join(\" \")'\n00000000 6fa006d1 Csaba Henk rm -rf testdir\nbash> ./gtr.sh testdir foobr\n\n* fa0c2b339d1f048281ed7098d8d7d55a12b35154 (HEAD, foobr) Rebase base.\n| * a87b990fcd5c7a109611694dcc9523d4f00ae8fe (topic) Topic.\n|/\n* 1e2d1c12f46105c9329479535780ec230afe7fa0 (master) Master.\n\n+ git hash-object .git/logs/HEAD\n734ae3b60eee21ee2b8b51450040389004d56e5d\n+ git rebase HEAD topic\nFirst, rewinding head to replay your work on top of it...\nApplying: Topic.\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nAuto-merging file\nCONFLICT (content): Merge conflict in file\nFailed to merge in the changes.\nPatch failed at 0001 Topic.\n\nWhen you have resolved this problem run \"git rebase --continue\".\nIf you would prefer to skip this patch, instead run \"git rebase --skip\".\nTo restore the original branch and stop rebasing run \"git rebase --abort\".\n\n+ :\n+ git hash-object .git/logs/HEAD\n5acf3d5f543333f549b3f9d295ed2ba91074b43d\n+ git reflog\nfa0c2b3 HEAD@{0}: checkout: moving from foobr to fa0c2b339d1f048281ed7098d8d7d55a12b35154^0\nfa0c2b3 HEAD@{1}: commit: Rebase base.\n1e2d1c1 HEAD@{2}: checkout: moving from topic to foobr\na87b990 HEAD@{3}: commit: Topic.\n1e2d1c1 HEAD@{4}: checkout: moving from master to topic\n1e2d1c1 HEAD@{5}: commit (initial): Master.\n+ cat .git/logs/HEAD\n+ ruby -ane 'puts $F.map{|x| x[0..(x =~ /:$/ ? -1 : 7)] }.join(\" \")'\n00000000 1e2d1c12 Csaba Henk writes:\n\n> \"git symbolic-ref\" is a dangerous command in the sense that it can\n> change your HEAD position without updating the reflog. Is it\n> intended behaviour?\n\nYes, it is. But you can choose to do:\n\n\t$ git branch side\n\t$ git symoblic-ref -m \"move to side\" HEAD refs/heads/side\n $ git log --oneline -g HEAD@{0}\n 05ddb9b HEAD@{0}: move to side\n\te69de29 HEAD@{1}: commit (initial): first commit\n\nif you wanted to.\n"},{"id":"166758","messageId":"BANLkTi=yDECQs=mVkEfrkrFfy0dgFf4U3Q@mail.gmail.com","threadId":"27219","inReplyTo":"7vk4edyqqn.fsf@alter.siamese.dyndns.org","subject":"Re: git symbolic-ref vs. reflog (vs. rebase)","fromName":"Csaba Henk","fromEmail":"csaba@lowlife.hu","sentAt":"2011-04-29T17:21:31Z","receivedAt":"2011-04-29T17:21:31Z","isPatch":false,"sender":{"key":"csaba@gluster.com","avatar":"https://avatars.githubusercontent.com/u/43937?v=4"},"body":"On Fri, Apr 29, 2011 at 9:49 PM, Junio C Hamano wrote:\n> Csaba Henk writes:\n>\n>> \"git symbolic-ref\" is a dangerous command in the sense that it can\n>> change your HEAD position without updating the reflog. Is it\n>> intended behaviour?\n>\n> Yes, it is.  But you can choose to do:\n>\n>        $ git branch side\n>        $ git symoblic-ref -m \"move to side\" HEAD refs/heads/side\n>        $ git log --oneline -g HEAD@{0}\n>        05ddb9b HEAD@{0}: move to side\n>        e69de29 HEAD@{1}: commit (initial): first commit\n>\n> if you wanted to.\n\nSo do you think the following patch would be the correct fix for the\nrebase issue:\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex cbb0ea9..10c1727 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -284,7 +284,7 @@ do\n head_name=\"$(cat \"$dotest\"/head-name)\" &&\n case \"$head_name\" in\n refs/*)\n- git symbolic-ref HEAD $head_name ||\n+ git symbolic-ref -m \"rebase: aborting\" HEAD\n$head_name ||\n die \"Could not move back to $head_name\"\n ;;\n esac\n\n\n?\n\nCsaba\n"},{"id":"166785","messageId":"20110429224829.GC3434@sigill.intra.peff.net","threadId":"27219","inReplyTo":"7vk4edyqqn.fsf@alter.siamese.dyndns.org","subject":"Re: git symbolic-ref vs. reflog (vs. rebase)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-29T22:48:30Z","receivedAt":"2011-04-29T22:48:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 29, 2011 at 09:19:44AM -0700, Junio C Hamano wrote:\n\n> Csaba Henk writes:\n> \n> > \"git symbolic-ref\" is a dangerous command in the sense that it can\n> > change your HEAD position without updating the reflog. Is it\n> > intended behaviour?\n> \n> Yes, it is. But you can choose to do:\n> \n> \t$ git branch side\n> \t$ git symoblic-ref -m \"move to side\" HEAD refs/heads/side\n> $ git log --oneline -g HEAD@{0}\n> 05ddb9b HEAD@{0}: move to side\n> \te69de29 HEAD@{1}: commit (initial): first commit\n> \n> if you wanted to.\n\nI think every caller should be using \"-m\" these days. I know we can't\n_require_ it for historical reasons. But shouldn't symbolic-ref always\nwrite a reflog entry? Even something like \"we changed and I can't tell\nyou why\" to cover older scripts that call symbolic-ref?\n\n-Peff\n"},{"id":"166790","messageId":"7vk4ecvf2c.fsf@alter.siamese.dyndns.org","threadId":"27219","inReplyTo":"20110429224829.GC3434@sigill.intra.peff.net","subject":"Re: git symbolic-ref vs. reflog (vs. rebase)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-29T23:00:11Z","receivedAt":"2011-04-29T23:00:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think every caller should be using \"-m\" these days. I know we can't\n> _require_ it for historical reasons. But shouldn't symbolic-ref always\n> write a reflog entry? Even something like \"we changed and I can't tell\n> you why\" to cover older scripts that call symbolic-ref?\n\nI think the particular instance Csaba saw in rebase may want to pass the\nreason why it flipped the HEAD.\n\nFlipping HEAD temporarily to another ref to do something, only to flip it\nback before giving the control back to the user, might be something a\nscript may want to have a choice of not logging, so I am mildly negative\non changing the command to unconditionally log empty entry without being\ntold.\n\n\"update-ref\" seems to write an empty entry even when not given an \"-m\"\noption, and we can view it as robbing a similar choice from the scripts.\nWe might want to fix it. I dunno.\n"},{"id":"166794","messageId":"20110430035819.GA4673@sigill.intra.peff.net","threadId":"27219","inReplyTo":"7vk4ecvf2c.fsf@alter.siamese.dyndns.org","subject":"Re: git symbolic-ref vs. reflog (vs. rebase)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-30T03:58:20Z","receivedAt":"2011-04-30T03:58:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 29, 2011 at 04:00:11PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I think every caller should be using \"-m\" these days. I know we can't\n> > _require_ it for historical reasons. But shouldn't symbolic-ref always\n> > write a reflog entry? Even something like \"we changed and I can't tell\n> > you why\" to cover older scripts that call symbolic-ref?\n> \n> I think the particular instance Csaba saw in rebase may want to pass the\n> reason why it flipped the HEAD.\n\nOh, definitely. I was thinking more for external scripts that we can't\nfix.\n\n> Flipping HEAD temporarily to another ref to do something, only to flip it\n> back before giving the control back to the user, might be something a\n> script may want to have a choice of not logging, so I am mildly negative\n> on changing the command to unconditionally log empty entry without being\n> told.\n\nYeah, that is a legitimate use case. But I suspect many scripts were\nsimply never updated after reflogs were introduced (or their authors)\nwere lazy, so they flip it once without a reflog, and then the next\nwell-behaved writer who comes along ends up writing a reflog entry that\nshows a hole.\n\nSo it is a question of whether helping probably-broken users is worth\nshutting off a legitimate use case. I also wonder how valuable that use\ncase is. As a user, I think I'd rather see _everything_ in the reflog,\neven if the script-writer doesn't think it's important.\n\nI don't know that it matters much in any case. We haven't had any bug\nreports either way; and given the current behavior, one can always yell\nat the script author to properly reflog.\n\n> \"update-ref\" seems to write an empty entry even when not given an \"-m\"\n> option, and we can view it as robbing a similar choice from the scripts.\n> We might want to fix it. I dunno.\n\nI'm inclined to wait until somebody actually wants it. In the meantime\nit helps users of old and/or broken scripts by providing an additional\ncheckpoint of state that might otherwise be missing.\n\n-Peff\n"},{"id":"166795","messageId":"20110430041312.GA5287@sigill.intra.peff.net","threadId":"27219","inReplyTo":"BANLkTi=yDECQs=mVkEfrkrFfy0dgFf4U3Q@mail.gmail.com","subject":"Re: git symbolic-ref vs. reflog (vs. rebase)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-04-30T04:13:12Z","receivedAt":"2011-04-30T04:13:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 29, 2011 at 10:51:31PM +0530, Csaba Henk wrote:\n\n> > Yes, it is.  But you can choose to do:\n> >\n> >        $ git branch side\n> >        $ git symoblic-ref -m \"move to side\" HEAD refs/heads/side\n> >        $ git log --oneline -g HEAD@{0}\n> >        05ddb9b HEAD@{0}: move to side\n> >        e69de29 HEAD@{1}: commit (initial): first commit\n> >\n> > if you wanted to.\n> \n> So do you think the following patch would be the correct fix for the\n> rebase issue:\n> \n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index cbb0ea9..10c1727 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -284,7 +284,7 @@ do\n> head_name=\"$(cat \"$dotest\"/head-name)\" &&\n> case \"$head_name\" in\n> refs/*)\n> - git symbolic-ref HEAD $head_name ||\n> + git symbolic-ref -m \"rebase: aborting\" HEAD\n> $head_name ||\n> die \"Could not move back to $head_name\"\n> ;;\n> esac\n\nI count 2 uses of symbolic-ref without reflogs in git-rebase, one more\nin git-rebase--interactive, and one in git-cvsexportcommit. Should all\nbe fixed to write a reflog entry?\n\nThe one in git-rebase.sh:move_to_original_branch even takes care to\nwrite a reflog message when updating the ref. So the branch reflog has\nan entry for the rebase being finished, but the HEAD reflog gets\nnothing. Presumably it's OK because we're moving from the detached\nversion of some commit to seeing it on the branch.\n\nWhat does a user expect? Personally I think it would be more readable to\nsee the extra entry. For example, this is from my current reflog:\n\n $ git log -g --oneline\n ...\n 50d3062 HEAD@{23}: checkout: moving from jk/merge-one-file to 50d3062ab2cea4e999b8f3bafd211ff348bca600\n 660fe6b HEAD@{24}: commit (amend): merge-one-file: fix broken merges with GIT_WORK_TREE\n ebad5e6 HEAD@{25}: commit (amend): merge-one-file: fix broken merges with GIT_WORK_TREE\n 306f37e HEAD@{26}: rebase -i (pick): merge-one-file: fix broken merges with GIT_WORK_TREE\n 0681894 HEAD@{27}: commit (amend): add tests for merge-index / merge-one-file\n 77d4cba HEAD@{28}: cherry-pick\n 50d3062 HEAD@{29}: checkout: moving from jk/merge-one-file to 50d3062ab2cea4e999b8f3bafd211ff348bca600\n ...\n\nSo reading in reverse order, I see that I started a rebase, which moved\nus to a detached HEAD, then picked and amended some commits. And then\nnothing, and suddenly I'm moving back from a branch to another detached\nHEAD (I rebased again). It would be easier to follow if HEAD{23} were\nactually:\n\n 660fe6b HEAD{23}: rebase finished: returning to jk/merge-one-file\n\nThis feels a little nit-picky. I have to admit I don't try to follow\nthese sorts of reflogs all the time, so it's not like this is a pressing\nissue. But when it comes to a user deciphering a broken state in their\nrepository, or trying to figure out which actions they took in a rebase\nlast week, the more entries we can give them, the better.\n\n-Peff\n"},{"id":"166842","messageId":"BANLkTimMCsXuP45WFDG-1FvkicLm5idKEQ@mail.gmail.com","threadId":"27219","inReplyTo":"7vk4ecvf2c.fsf@alter.siamese.dyndns.org","subject":"Re: git symbolic-ref vs. reflog (vs. rebase)","fromName":"Csaba Henk","fromEmail":"csaba@lowlife.hu","sentAt":"2011-05-02T08:38:28Z","receivedAt":"2011-05-02T08:38:28Z","isPatch":false,"sender":{"key":"csaba@gluster.com","avatar":"https://avatars.githubusercontent.com/u/43937?v=4"},"body":"On Sat, Apr 30, 2011 at 4:30 AM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> I think every caller should be using \"-m\" these days.  I know we can't\n>> _require_ it for historical reasons. But shouldn't symbolic-ref always\n>> write a reflog entry? Even something like \"we changed and I can't tell\n>> you why\" to cover older scripts that call symbolic-ref?\n>\n> I think the particular instance Csaba saw in rebase may want to pass the\n> reason why it flipped the HEAD.\n>\n> Flipping HEAD temporarily to another ref to do something, only to flip it\n> back before giving the control back to the user, might be something a\n> script may want to have a choice of not logging, so I am mildly negative\n> on changing the command to unconditionally log empty entry without being\n> told.\n>\n> \"update-ref\" seems to write an empty entry even when not given an \"-m\"\n> option, and we can view it as robbing a similar choice from the scripts.\n> We might want to fix it.  I dunno.\n\nWhat if symbolic-ref and/or update-ref were changed so that the default\ninvocation would add a reflog entry with a default (empty?) note, however,\nalso provide an option with which suppressing the reflog can be requested?\n\nCsaba\n"},{"id":"166844","messageId":"BANLkTinyKQJQUHa8tn43=cCJMsVbgaZXjA@mail.gmail.com","threadId":"27219","inReplyTo":"20110430041312.GA5287@sigill.intra.peff.net","subject":"Re: git symbolic-ref vs. reflog (vs. rebase)","fromName":"Csaba Henk","fromEmail":"csaba@lowlife.hu","sentAt":"2011-05-02T08:46:02Z","receivedAt":"2011-05-02T08:46:02Z","isPatch":false,"sender":{"key":"csaba@gluster.com","avatar":"https://avatars.githubusercontent.com/u/43937?v=4"},"body":"On Sat, Apr 30, 2011 at 9:43 AM, Jeff King wrote:\n> On Fri, Apr 29, 2011 at 10:51:31PM +0530, Csaba Henk wrote:\n>\n>> > Yes, it is.  But you can choose to do:\n>> >\n>> >        $ git branch side\n>> >        $ git symoblic-ref -m \"move to side\" HEAD refs/heads/side\n>> >        $ git log --oneline -g HEAD@{0}\n>> >        05ddb9b HEAD@{0}: move to side\n>> >        e69de29 HEAD@{1}: commit (initial): first commit\n>> >\n>> > if you wanted to.\n>>\n>> So do you think the following patch would be the correct fix for the\n>> rebase issue:\n>>\n>> diff --git a/git-rebase.sh b/git-rebase.sh\n>> index cbb0ea9..10c1727 100755\n>> --- a/git-rebase.sh\n>> +++ b/git-rebase.sh\n>> @@ -284,7 +284,7 @@ do\n>>                 head_name=\"$(cat \"$dotest\"/head-name)\" &&\n>>                 case \"$head_name\" in\n>>                 refs/*)\n>> -                       git symbolic-ref HEAD $head_name ||\n>> +                       git symbolic-ref -m \"rebase: aborting\" HEAD\n>> $head_name ||\n>>                         die \"Could not move back to $head_name\"\n>>                         ;;\n>>                 esac\n>\n> I count 2 uses of symbolic-ref without reflogs in git-rebase, one more\n> in git-rebase--interactive, and one in git-cvsexportcommit. Should all\n> be fixed to write a reflog entry?\n\nYeah, that's why I didn't set the above patch as PATCH -- I lack the insight\nto rebase / plumbing in general to be able to propose a change with the right\nimpact.\n\nCsaba\n"},{"id":"168896","messageId":"20110527201302.GA29836@sigill.intra.peff.net","threadId":"27219","inReplyTo":"BANLkTinyKQJQUHa8tn43=cCJMsVbgaZXjA@mail.gmail.com","subject":"[PATCH 1/2] rebase: create HEAD reflog entry when aborting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-27T20:13:02Z","receivedAt":"2011-05-27T20:13:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"From: Csaba Henk \n\nWhen we abort a rebase, we return to the original value of\nHEAD. Failing to write a reflog entry means we create a\ngap in the reflog (which can cause \"git show\nHEAD@{5.minutes.ago}\" to issue a warning). Plus having the\nextra entry makes the reflog easier to follow for a human.\n\nSigned-off-by: Jeff King \n---\nThis is the one that actually gave you trouble. It's different than\nother cases (dealt with in 2/2) in that it actually creates a gap in the\nreflog. So I think fixing it is the right thing to do, and your original\npatch is fine.\n\n git-rebase.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 7a54bfc..57cbe49 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -332,7 +332,7 @@ abort)\n \tread_basic_state\n \tcase \"$head_name\" in\n \trefs/*)\n-\t\tgit symbolic-ref HEAD $head_name ||\n+\t\tgit symbolic-ref -m \"rebase: aborting\" HEAD $head_name ||\n \t\tdie \"Could not move back to $head_name\"\n \t\t;;\n \tesac\n-- \n1.7.5.3.12.g99e25\n"},{"id":"168897","messageId":"20110527201614.GB29836@sigill.intra.peff.net","threadId":"27219","inReplyTo":"BANLkTinyKQJQUHa8tn43=cCJMsVbgaZXjA@mail.gmail.com","subject":"[PATCH 2/2] rebase: write a reflog entry when finishing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-27T20:16:14Z","receivedAt":"2011-05-27T20:16:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"When we finish a rebase, our detached HEAD is at the final\nresult. We update the original branch ref with this result,\nand then point the HEAD symbolic ref at the updated branch.\nWe write a reflog for the branch update, but not for the\nupdate of HEAD.\n\nBecause we're already at the final result on the detached\nHEAD, moving to the branch actually doesn't change our\ncommit sha1 at all. So in that sense, a reflog entry would\nbe pointless.\n\nHowever, humans do read reflogs, and an entry saying \"rebase\nfinished: returning to refs/heads/master\" can be helpful in\nunderstanding what is going on.\n\nSigned-off-by: Jeff King \n---\nSee the minor test update for an example of how this could break people\nor scripts who assume they know what's at which point in the reflog. In\ngeneral I think all bets are off with HEAD, because commands do their\nwork on a detached HEAD, and then provide a nice single-entry result in\nthe branch reflog (which is why I switched the test to use the more\nstable master@{1}).\n\n git-rebase--interactive.sh | 4 +++-\n git-rebase.sh | 4 +++-\n t/t3404-rebase-interactive.sh | 2 +-\n 3 files changed, 7 insertions(+), 3 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 41ba96a..65690af 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -510,7 +510,9 @@ do_next () {\n \trefs/*)\n \t\tmessage=\"$GIT_REFLOG_ACTION: $head_name onto $shortonto\" &&\n \t\tgit update-ref -m \"$message\" $head_name $newhead $orig_head &&\n-\t\tgit symbolic-ref HEAD $head_name\n+\t\tgit symbolic-ref \\\n+\t\t -m \"$GIT_REFLOG_ACTION: returning to $head_name\" \\\n+\t\t HEAD $head_name\n \t\t;;\n \tesac && {\n \t\ttest ! -f \"$state_dir\"/verbose ||\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 57cbe49..d7855ea 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -153,7 +153,9 @@ move_to_original_branch () {\n \t\tmessage=\"rebase finished: $head_name onto $onto\"\n \t\tgit update-ref -m \"$message\" \\\n \t\t\t$head_name $(git rev-parse HEAD) $orig_head &&\n-\t\tgit symbolic-ref HEAD $head_name ||\n+\t\tgit symbolic-ref \\\n+\t\t\t-m \"rebase finished: returning to $head_name\" \\\n+\t\t\tHEAD $head_name ||\n \t\tdie \"Could not move back to $head_name\"\n \t\t;;\n \tesac\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex 7d8147b..47c8371 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -317,7 +317,7 @@ test_expect_success '--continue tries to commit' '\n '\n \n test_expect_success 'verbose flag is heeded, even after --continue' '\n-\tgit reset --hard HEAD@{1} &&\n+\tgit reset --hard master@{1} &&\n \ttest_tick &&\n \ttest_must_fail git rebase -v -i --onto new-branch1 HEAD^ &&\n \techo resolved > file1 &&\n-- \n1.7.5.3.12.g99e25\n"}]}