{"thread":{"id":"24878","subject":"git pull --rebase differs in behavior from git fetch + git rebase","startedAt":"2010-08-27T02:59:13Z","lastAt":"2010-08-28T03:13:03Z","messageCount":10,"participants":["Joshua Jensen","Santi Béjar","Dave Olszewski","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"149100","messageId":"4C772A01.5030207@workspacewhiz.com","threadId":"24878","inReplyTo":null,"subject":"git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2010-08-27T02:59:13Z","receivedAt":"2010-08-27T02:59:13Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"  I have a case where 'git pull --rebase' does not do the Right Thing \n(according to me).\n\nIf I run 'git rebase origin/master', that rebase does the right thing, \nperfectly reapplying my *single* commit on top of the upstream.\n\n'git pull --rebase' ends up reapplying a bunch of much earlier commits \nand ends up with a conflict.\n\nThe documentation for git pull --rebase states: \"Instead of a merge, \nperform a rebase after fetching. If there is a remote ref for the \nupstream branch, and this branch was rebased since last fetched, the \nrebase uses that information to avoid rebasing non-local changes.\"  I do \nnot understand\n\nI'm studying the git-pull script right now, but I have to admit this is \nbeyond me.  I'm sure if I stare hard enough, I'll get it.\n\nI mistakenly have assumed 'git pull' = 'git fetch; git merge' and that \n'git pull --rebase' = 'git fetch; git rebase'.  Does anyone want to \nclarify what is really going on?  Unfortunately, I can't publish the \nrepository in question.\n\nThanks!\n\nJosh\n"},{"id":"149111","messageId":"AANLkTi=w_XgAzt=ekQWKvaZj+Q3bXedOXkdy5+7Vzg_s@mail.gmail.com","threadId":"24878","inReplyTo":"4C772A01.5030207@workspacewhiz.com","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2010-08-27T07:23:12Z","receivedAt":"2010-08-27T07:23:12Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"Can you try the latest master branch of git.git?\n\nSanti\n"},{"id":"149114","messageId":"alpine.DEB.2.00.1008270124450.20874@narbuckle.genericorp.net","threadId":"24878","inReplyTo":"4C772A01.5030207@workspacewhiz.com","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Dave Olszewski","fromEmail":"cxreg@pobox.com","sentAt":"2010-08-27T08:27:41Z","receivedAt":"2010-08-27T08:27:41Z","isPatch":false,"sender":{"key":"cxreg@pobox.com","avatar":"https://avatars.githubusercontent.com/u/55474?v=4"},"body":"On Thu, 26 Aug 2010, Joshua Jensen wrote:\n\n> I have a case where 'git pull --rebase' does not do the Right Thing \n> (according to me).\n>\n> If I run 'git rebase origin/master', that rebase does the right thing, \n> perfectly reapplying my *single* commit on top of the upstream.\n>\n> 'git pull --rebase' ends up reapplying a bunch of much earlier commits and \n> ends up with a conflict.\n>\n> The documentation for git pull --rebase states: \"Instead of a merge, perform \n> a rebase after fetching. If there is a remote ref for the upstream branch, \n> and this branch was rebased since last fetched, the rebase uses that \n> information to avoid rebasing non-local changes.\"  I do not understand\n>\n> I'm studying the git-pull script right now, but I have to admit this is \n> beyond me.  I'm sure if I stare hard enough, I'll get it.\n>\n> I mistakenly have assumed 'git pull' = 'git fetch; git merge' and that 'git \n> pull --rebase' = 'git fetch; git rebase'.  Does anyone want to clarify what \n> is really going on?  Unfortunately, I can't publish the repository in \n> question.\n\nAre you by any chance running a git with commit cf65426de?  If not, give\nit a try and see if it corrects your issue.\n\nThe main difference between \"git pull --rebase\" and \"git fetch && git\nrebase @{u}\" is that \"git pull --rebase\" will attempt to use the reflog\nto find a suitable \"upstream\" candidate instead of assuming your\ntracking branch is the upstream itself.  This is intended to help\nrecover from upstream rebases, but has adverse effects sometimes, which\ncommit cf65426de should help with.\n\n     Dave\n"},{"id":"149126","messageId":"4C77DE60.6020809@workspacewhiz.com","threadId":"24878","inReplyTo":"alpine.DEB.2.00.1008270124450.20874@narbuckle.genericorp.net","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2010-08-27T15:48:48Z","receivedAt":"2010-08-27T15:48:48Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"  ----- Original Message -----\nFrom: Dave Olszewski\nDate: 8/27/2010 2:27 AM\n> On Thu, 26 Aug 2010, Joshua Jensen wrote:\n>\n>> I have a case where 'git pull --rebase' does not do the Right Thing \n>> (according to me).\n>>\n>> If I run 'git rebase origin/master', that rebase does the right \n>> thing, perfectly reapplying my *single* commit on top of the upstream.\n>>\n>> 'git pull --rebase' ends up reapplying a bunch of much earlier \n>> commits and ends up with a conflict.\n>>\n>> The documentation for git pull --rebase states: \"Instead of a merge, \n>> perform a rebase after fetching. If there is a remote ref for the \n>> upstream branch, and this branch was rebased since last fetched, the \n>> rebase uses that information to avoid rebasing non-local changes.\"  I \n>> do not understand\n>>\n>> I'm studying the git-pull script right now, but I have to admit this \n>> is beyond me.  I'm sure if I stare hard enough, I'll get it.\n>>\n>> I mistakenly have assumed 'git pull' = 'git fetch; git merge' and \n>> that 'git pull --rebase' = 'git fetch; git rebase'.  Does anyone want \n>> to clarify what is really going on?  Unfortunately, I can't publish \n>> the repository in question.\n>\n> Are you by any chance running a git with commit cf65426de?  If not, give\n> it a try and see if it corrects your issue.\nI was not, but now I am.\n> The main difference between \"git pull --rebase\" and \"git fetch && git\n> rebase @{u}\" is that \"git pull --rebase\" will attempt to use the reflog\n> to find a suitable \"upstream\" candidate instead of assuming your\n> tracking branch is the upstream itself.  This is intended to help\n> recover from upstream rebases, but has adverse effects sometimes, which\n> commit cf65426de should help with.\nUnfortunately, commit cf65426de helps only a little.  The 'git pull \n--rebase' reports \"Nothing to do\" and moves the master branch to \norigin/master, leaving behind the commit needing to be rebased.\n\nWhat else might there be to try?  I would like to help with a repro, if \npossible.\n\nJosh\n"},{"id":"149137","messageId":"AANLkTimEO==c7Pzi99VfvDp7S9HN=V2j6t0kk--w1kb9@mail.gmail.com","threadId":"24878","inReplyTo":"4C77DE60.6020809@workspacewhiz.com","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2010-08-27T18:46:53Z","receivedAt":"2010-08-27T18:46:53Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Aug 27, 2010 at 9:48 AM, Joshua Jensen\n<jjensen@workspacewhiz.com> wrote:\n>> The main difference between \"git pull --rebase\" and \"git fetch && git\n>> rebase @{u}\" is that \"git pull --rebase\" will attempt to use the reflog\n>> to find a suitable \"upstream\" candidate instead of assuming your\n>> tracking branch is the upstream itself.  This is intended to help\n>> recover from upstream rebases, but has adverse effects sometimes, which\n>> commit cf65426de should help with.\n>\n> Unfortunately, commit cf65426de helps only a little.  The 'git pull\n> --rebase' reports \"Nothing to do\" and moves the master branch to\n> origin/master, leaving behind the commit needing to be rebased.\n>\n> What else might there be to try?  I would like to help with a repro, if\n> possible.\n\nTry modifying the git-pull script; change the last line from\n  eval \"exec $eval\"\nto\n  echo \"exec $eval\"\n.\n\nIs the output of the form\n  git-rebase --onto XXXX YYYY\nor\n  git-rebase --onto XXXX XXXX\n?\n\nWith cf65426de, and from what I'm guessing from your description, I'd\nexpect the latter.  And, I'd assume the latter is equivalent to\n'git-rebase XXXX', but you say that's not the behavior you're getting.\n Finding out which of my assumptions is wrong may help you debug the\nissue.\n"},{"id":"149146","messageId":"4C783C66.3000008@workspacewhiz.com","threadId":"24878","inReplyTo":"AANLkTimEO==c7Pzi99VfvDp7S9HN=V2j6t0kk--w1kb9@mail.gmail.com","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2010-08-27T22:29:58Z","receivedAt":"2010-08-27T22:29:58Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"  ----- Original Message -----\nFrom: Elijah Newren\nDate: 8/27/2010 12:46 PM\n> On Fri, Aug 27, 2010 at 9:48 AM, Joshua Jensen\n> <jjensen@workspacewhiz.com>  wrote:\n>>> The main difference between \"git pull --rebase\" and \"git fetch&&  git\n>>> rebase @{u}\" is that \"git pull --rebase\" will attempt to use the reflog\n>>> to find a suitable \"upstream\" candidate instead of assuming your\n>>> tracking branch is the upstream itself.  This is intended to help\n>>> recover from upstream rebases, but has adverse effects sometimes, which\n>>> commit cf65426de should help with.\n>> Unfortunately, commit cf65426de helps only a little.  The 'git pull\n>> --rebase' reports \"Nothing to do\" and moves the master branch to\n>> origin/master, leaving behind the commit needing to be rebased.\n>>\n>> What else might there be to try?  I would like to help with a repro, if\n>> possible.\n> Try modifying the git-pull script; change the last line from\n>    eval \"exec $eval\"\n> to\n>    echo \"exec $eval\"\n> .\n>\n> Is the output of the form\n>    git-rebase --onto XXXX YYYY\n> or\n>    git-rebase --onto XXXX XXXX\n> ?\n>\n> With cf65426de, and from what I'm guessing from your description, I'd\n> expect the latter.  And, I'd assume the latter is equivalent to\n> 'git-rebase XXXX', but you say that's not the behavior you're getting.\n>   Finding out which of my assumptions is wrong may help you debug the\n> issue.\nIt reports to me 'git-rebase --onto XXXX XXXX'.\n\nAnd it reports nothing to do.\n\nXXXX is properly the origin/master in this case.\n\ngit rebase origin/master           works.\ngit rebase --onto origin/master origin/master       does not work.\n\nThoughts?\n\nJosh\n"},{"id":"149147","messageId":"AANLkTimBv3EVWaEnateD95sUi_LkmNw8RKJZYrW4dUFy@mail.gmail.com","threadId":"24878","inReplyTo":"4C783C66.3000008@workspacewhiz.com","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2010-08-27T23:40:21Z","receivedAt":"2010-08-27T23:40:21Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Aug 27, 2010 at 4:29 PM, Joshua Jensen\n<jjensen@workspacewhiz.com> wrote:\n> It reports to me 'git-rebase --onto XXXX XXXX'.\n>\n> And it reports nothing to do.\n>\n> XXXX is properly the origin/master in this case.\n>\n> git rebase origin/master           works.\n> git rebase --onto origin/master origin/master       does not work.\n>\n> Thoughts?\n\nIt's too bad you can't make this repository public; I thought rebase\nshould behave the same for those two commands.  We could certainly\njust modify git-pull.sh to avoid using the --onto flag when\noldremoteref is not defined (and perhaps that makes sense independent\nof anything else), but I'm curious now about rebase.\n\nCan you insert an echo statement right before where git-rebase calls\nformat-patch to see what arguments it is passing in those two cases?\nFor me it's around line 568; insert an echo statement so that it looks\nlike:\n if test -z \"$do_merge\"\n then\n        echo git format-patch -k --stdout --full-index --ignore-if-in-upstream \\\n               --no-renames $root_flag \"$revisions\"\n        git format-patch -k --stdout --full-index --ignore-if-in-upstream \\\n                --no-renames $root_flag \"$revisions\" |\n        git am $git_am_opt --rebasing --resolvemsg=\"$RESOLVEMSG\" &&\nMake that change, and then run it with both your rebase commands and\nsee what you get.\n\nFor me, in both cases, I get:\n  git format-patch ... --no-renames origin/master..HEAD\n(except sha1sums of what origin/master and HEAD were rather than that\nliteral text), which means the same patches are being applied in both\ncases for me.\n\nElijah\n"},{"id":"149151","messageId":"4C786F36.3060107@workspacewhiz.com","threadId":"24878","inReplyTo":"AANLkTimBv3EVWaEnateD95sUi_LkmNw8RKJZYrW4dUFy@mail.gmail.com","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2010-08-28T02:06:46Z","receivedAt":"2010-08-28T02:06:46Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"  ----- Original Message -----\nFrom: Elijah Newren\nDate: 8/27/2010 5:40 PM\n> On Fri, Aug 27, 2010 at 4:29 PM, Joshua Jensen\n> <jjensen@workspacewhiz.com>  wrote:\n>> It reports to me 'git-rebase --onto XXXX XXXX'.\n>>\n>> And it reports nothing to do.\n>>\n>> XXXX is properly the origin/master in this case.\n>>\n>> git rebase origin/master           works.\n>> git rebase --onto origin/master origin/master       does not work.\n>>\n>> Thoughts?\n> It's too bad you can't make this repository public; I thought rebase\n> should behave the same for those two commands.  We could certainly\n> just modify git-pull.sh to avoid using the --onto flag when\n> oldremoteref is not defined (and perhaps that makes sense independent\n> of anything else), but I'm curious now about rebase.\n>\n> Can you insert an echo statement right before where git-rebase calls\n> format-patch to see what arguments it is passing in those two cases?\n> For me it's around line 568; insert an echo statement so that it looks\n> like:\n>   if test -z \"$do_merge\"\n>   then\n>          echo git format-patch -k --stdout --full-index --ignore-if-in-upstream \\\n>                 --no-renames $root_flag \"$revisions\"\n>          git format-patch -k --stdout --full-index --ignore-if-in-upstream \\\n>                  --no-renames $root_flag \"$revisions\" |\n>          git am $git_am_opt --rebasing --resolvemsg=\"$RESOLVEMSG\"&&\n> Make that change, and then run it with both your rebase commands and\n> see what you get.\n>\n> For me, in both cases, I get:\n>    git format-patch ... --no-renames origin/master..HEAD\n> (except sha1sums of what origin/master and HEAD were rather than that\n> literal text), which means the same patches are being applied in both\n> cases for me.\nOkay, there is _not_ a problem with the patch in 1.7.2.2 for the \n\"broken\" repository I have in front of me right now, but I wish I hadn't \ntrashed the other broken repository someone else had.  :(\n\nBefore running a successful 'git rebase origin/master' on the broken \nrepository, I made a copy of it.  That person then committed and pushed \nthe rebased commit.  _I did not know that._\n\nI copied the broken repository into two locations, testrebase and \ntestpullrebase.\n\nIn the testrebase repository, I ran 'git rebase origin/master'.  I did \nnot fetch, so the repository was in the same state as the original \nbroken copy.\n\nIn the testpullrebase repository, I ran 'git pull --rebase'.  It fetched \nthe latest commits (which included the person's pushed rebase commit), \nand I saw it supposedly didn't rebase the commit.  However, it did the \nRIGHT thing, because the commit already exists in the repository.\n\nSorry for causing an issue, but I definitely appreciate the fix already \nbeing available.\n\nJosh\n"},{"id":"149153","messageId":"AANLkTimz4P3EGnZntQubL06ZqXREiDTDVk+fb9VVLDKN@mail.gmail.com","threadId":"24878","inReplyTo":"4C786F36.3060107@workspacewhiz.com","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2010-08-28T02:40:49Z","receivedAt":"2010-08-28T02:40:49Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Aug 27, 2010 at 8:06 PM, Joshua Jensen\n<jjensen@workspacewhiz.com> wrote:\n> Okay, there is _not_ a problem with the patch in 1.7.2.2 for the \"broken\"\n> repository I have in front of me right now, but I wish I hadn't trashed the\n> other broken repository someone else had.  :(\n>\n\n> Sorry for causing an issue, but I definitely appreciate the fix already\n> being available.\n\nNot a problem; it's totally understandable.  Believe me, I had a whole\nbunch of similar problems when trying to deal with this bug when\npeople were hitting it at work (e.g. trying to duplicate by cloning,\nwhich never worked since the bug depended on reflog state).\n\nIn any event, I'm glad it's working for you now.  :-)\n\nElijah\n"},{"id":"149154","messageId":"4C787EBF.7010802@workspacewhiz.com","threadId":"24878","inReplyTo":"AANLkTimz4P3EGnZntQubL06ZqXREiDTDVk+fb9VVLDKN@mail.gmail.com","subject":"Re: git pull --rebase differs in behavior from git fetch + git rebase","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2010-08-28T03:13:03Z","receivedAt":"2010-08-28T03:13:03Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"  ----- Original Message -----\nFrom: Elijah Newren\nDate: 8/27/2010 8:40 PM\n> On Fri, Aug 27, 2010 at 8:06 PM, Joshua Jensen\n> <jjensen@workspacewhiz.com>  wrote:\n>> Okay, there is _not_ a problem with the patch in 1.7.2.2 for the \"broken\"\n>> repository I have in front of me right now, but I wish I hadn't trashed the\n>> other broken repository someone else had.  :(\nAs it turns out, the other broken repository exists still, but it will \nbe Monday before I can test against the 1.7.2.2 change.\n>> Sorry for causing an issue, but I definitely appreciate the fix already\n>> being available.\n> Not a problem; it's totally understandable.  Believe me, I had a whole\n> bunch of similar problems when trying to deal with this bug when\n> people were hitting it at work (e.g. trying to duplicate by cloning,\n> which never worked since the bug depended on reflog state).\nFortunately, I've worked with Git long enough now that I knew to direct \ncopy the .git folder to the new location, 'git reset --hard' to get the \nfiles back, and hopefully then be in the same state.\n> In any event, I'm glad it's working for you now.  :-)\nMe, too.\n\nNow, if only 'git rebase --preserve-merges' would work all the time and \ncould be the default.  (I have instances where a topic branch is merged \nback to master with --no-ff to generate the merge commit, an attempt is \nmade to push but new commits have been added from others, so a pull \n--rebase is performed and ends up replaying the merge linearly... no \nmerge commit... oh, well.)\n\nTake care.\n\nJosh\n"}]}