{"thread":{"id":"22112","subject":"Difference between pull --rebase and fetch+rebase","startedAt":"2010-01-07T12:23:22Z","lastAt":"2010-01-08T19:41:16Z","messageCount":8,"participants":["martinvz","Santi Béjar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"130992","messageId":"27059158.post@talk.nabble.com","threadId":"22112","inReplyTo":null,"subject":"Difference between pull --rebase and fetch+rebase","fromName":"martinvz","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-01-07T12:23:22Z","receivedAt":"2010-01-07T12:23:22Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"\nI have a branch configured to track a remote branch by rebasing. I excepted\nthat \"git pull\" would therefore be equivalent to fetching from the remote\nrepository followed by rebasing the remote branch, but it isn't. When doing\n\"git rebase /\", it applies only the commits after the merge\nbase. When doing \"git pull\", it tries to apply two more commits (the two\ncommits preceding the merge base). Why is this?\n\nI get the same result even if I do \"git pull --rebase \", it\ndoesn't seem to have anything to do with incorrect configuration of the\nbranch.\n-- \nView this message in context: http://old.nabble.com/Difference-between-pull---rebase-and-fetch%2Brebase-tp27059158p27059158.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"130993","messageId":"27059574.post@talk.nabble.com","threadId":"22112","inReplyTo":"27059158.post@talk.nabble.com","subject":"Re: Difference between pull --rebase and fetch+rebase","fromName":"martinvz","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-01-07T12:58:04Z","receivedAt":"2010-01-07T12:58:04Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"\nForgot to say that I am using version 1.6.5.1.1367.gcd48 (Cygwin). I should\nalso say that I can see no particular reason why exactly two extra commits\nwere picked.\n\n\nmartinvz wrote:\n> \n> I have a branch configured to track a remote branch by rebasing. I\n> excepted that \"git pull\" would therefore be equivalent to fetching from\n> the remote repository followed by rebasing the remote branch, but it\n> isn't. When doing \"git rebase /\", it applies only the\n> commits after the merge base. When doing \"git pull\", it tries to apply two\n> more commits (the two commits preceding the merge base). Why is this?\n> \n> I get the same result even if I do \"git pull --rebase \",\n> it doesn't seem to have anything to do with incorrect configuration of the\n> branch.\n> \n\n-- \nView this message in context: http://old.nabble.com/Difference-between-pull---rebase-and-fetch%2Brebase-tp27059158p27059574.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"131002","messageId":"adf1fd3d1001070800k6fa501fej39b84f849b7e5b50@mail.gmail.com","threadId":"22112","inReplyTo":"27059158.post@talk.nabble.com","subject":"Re: Difference between pull --rebase and fetch+rebase","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2010-01-07T16:00:36Z","receivedAt":"2010-01-07T16:00:36Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Thu, Jan 7, 2010 at 1:23 PM, martinvz\n wrote:\n>\n> I have a branch configured to track a remote branch by rebasing. I excepted\n> that \"git pull\" would therefore be equivalent to fetching from the remote\n> repository followed by rebasing the remote branch, but it isn't. When doing\n> \"git rebase /\", it applies only the commits after the merge\n> base. When doing \"git pull\", it tries to apply two more commits (the two\n> commits preceding the merge base). Why is this?\n>\n> I get the same result even if I do \"git pull --rebase \", it\n> doesn't seem to have anything to do with incorrect configuration of the\n> branch.\n\nYes, both should do the same (at least when upstream is not rebased).\nCan you provide a test case or instructions to reproduce the behavior?\n\nThanks,\nSanti\n"},{"id":"131032","messageId":"1262889864880-4268064.post@n2.nabble.com","threadId":"22112","inReplyTo":"adf1fd3d1001070800k6fa501fej39b84f849b7e5b50@mail.gmail.com","subject":"Re: Difference between pull --rebase and fetch+rebase","fromName":"martinvz","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-01-07T18:44:24Z","receivedAt":"2010-01-07T18:44:24Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"\nThanks for your post, Santi. I can not share my repository since it is a\nproject at work. I was troubleshooting a bit myself and found the following\nsection in git-pull.sh:\n\n\toldremoteref=\"$(git rev-parse -q --verify \"$remoteref\")\" &&\n\tfor reflog in $(git rev-list -g $remoteref 2>/dev/null)\n\tdo\n\t\tif test \"$reflog\" = \"$(git merge-base $reflog $curr_branch)\"\n\t\tthen\n\t\t\toldremoteref=\"$reflog\"\n\t\t\tbreak\n\t\tfi\n\tdone\n\nWhy is it that reflog entries are allowed to override the remote reference?\n\n\nThanks,\nMartin\n\n\n\nSanti Béjar-2 wrote:\n> \n> On Thu, Jan 7, 2010 at 1:23 PM, martinvz\n> wrote:\n>>\n>> I have a branch configured to track a remote branch by rebasing. I\n>> excepted\n>> that \"git pull\" would therefore be equivalent to fetching from the remote\n>> repository followed by rebasing the remote branch, but it isn't. When\n>> doing\n>> \"git rebase /\", it applies only the commits after the\n>> merge\n>> base. When doing \"git pull\", it tries to apply two more commits (the two\n>> commits preceding the merge base). Why is this?\n>>\n>> I get the same result even if I do \"git pull --rebase \",\n>> it\n>> doesn't seem to have anything to do with incorrect configuration of the\n>> branch.\n> \n> Yes, both should do the same (at least when upstream is not rebased).\n> Can you provide a test case or instructions to reproduce the behavior?\n> \n> Thanks,\n> Santi\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n> \n\n-- \nView this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4268064.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"131050","messageId":"adf1fd3d1001071433j6cd36641sdd2dfd6a936d8483@mail.gmail.com","threadId":"22112","inReplyTo":"1262889864880-4268064.post@n2.nabble.com","subject":"Re: Difference between pull --rebase and fetch+rebase","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2010-01-07T22:33:23Z","receivedAt":"2010-01-07T22:33:23Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"[Do not top post, as it breaks the conversation flow]\n\nOn Thu, Jan 7, 2010 at 7:44 PM, martinvz\n wrote:\n>\n> Thanks for your post, Santi. I can not share my repository since it is a\n> project at work. I was troubleshooting a bit myself and found the following\n> section in git-pull.sh:\n>\n>        oldremoteref=\"$(git rev-parse -q --verify \"$remoteref\")\" &&\n>        for reflog in $(git rev-list -g $remoteref 2>/dev/null)\n>        do\n>                if test \"$reflog\" = \"$(git merge-base $reflog $curr_branch)\"\n>                then\n>                        oldremoteref=\"$reflog\"\n>                        break\n>                fi\n>        done\n>\n> Why is it that reflog entries are allowed to override the remote reference?\n\nThis is used when the upstream branch is rebased, as you only want to\nrebase the local commits and not commits in the old upstream branch.\n\nIs your upstream branch rebased?\n\nCan you provide, at least, a graph of your history (ala git log\n--graph --oneline for example)? And plot also the reflog entries and\nall the important commits.\n\nSanti\n"},{"id":"131052","messageId":"1262907485376-4269422.post@n2.nabble.com","threadId":"22112","inReplyTo":"adf1fd3d1001071433j6cd36641sdd2dfd6a936d8483@mail.gmail.com","subject":"Re: Difference between pull --rebase and fetch+rebase","fromName":"martinvz","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-01-07T23:38:05Z","receivedAt":"2010-01-07T23:38:05Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"\n\nSanti Béjar-2 wrote:\n> \n> Is your upstream branch rebased?\n> \n\nSorry, but I'm not sure I understand what that means. Most of the commits in\nthe upstream branch (the remote main branch) were rebased onto that branch\nat some point in time before being pushed to our shared repository. The\nremote branch itself was never rebased against any other branch (all\ndestructive operations disallowed in Gitosis). I hope that (possibly along\nwith the information below) answers your question.\n\n\nSanti Béjar-2 wrote:\n> \n> Can you provide, at least, a graph of your history (ala git log\n> --graph --oneline for example)? And plot also the reflog entries and\n> all the important commits.\n> \n\n$ git log --graph --format=%h --all\n* 2038a46 # topic-2\n* a7b93b2\n* f2501ae # origin/main\n* cd5aaa9\n* cb232f3\n...\n* 5ed0d06\n* 3067862\n| * 6eba2fa # topic-1\n| * b09aaf4\n| * bc3b72a\n|/\n| * 03d0d84 # topic-3\n| * 5160773\n| * 3c25642\n|/\n| * 6e9b12b # topic-4\n| * 75f5ab2\n| * bdd08ce\n| * b5d5759\n|/\n* 486b580\n* a021696\n* 3ffe7df\n* d0f55c5\n...\n\nI have topic-1 checked out and run \"git pull\" and expect it to rebase (only)\ncommits bc3b72a, b09aaf4, 6eba2fa onto f2501ae, but it starts by applying\na021696 and 486b580.\n\n$ git reflog -g origin/main\nf2501ae refs/remotes/origin/main@{0}: fetch origin: fast forward\n3ffe7df refs/remotes/origin/main@{1}: fetch origin: fast forward\n...\n\nI hope that's all that's all you need. It seems that the problem is that the\noldremoteref gets overwritten with the entry from the reflog. Is the problem\nthat 3ffe7df appears in the reflog or that 486b580 doesn't appear there? I'm\nnot clear on what ends up in the reflog.\n\nI just realized that I myself created a021696 and 486b580 (but not 3ffe7df),\nprobably by rebasing some now-dead branch against origin/main.\n\nSomething else that may or may not have something to do with the problem is\nthat there is also a branch called origin/main-stable (pointing to the same\ncommit as origin/main). I also have a local main branch (also same commit as\norigin/main). I don't know if any of this could confuse Git. (To be\nperfectly honest, it is actually the origin/main-stable branch I'm trying to\npull from, just in case you think the branch name could have any impact.)\n\n\nThanks,\nMartin\n\n-- \nView this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4269422.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"131077","messageId":"adf1fd3d1001080305k138a2670k17a126cc0b8430b8@mail.gmail.com","threadId":"22112","inReplyTo":"1262907485376-4269422.post@n2.nabble.com","subject":"Re: Difference between pull --rebase and fetch+rebase","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2010-01-08T11:05:40Z","receivedAt":"2010-01-08T11:05:40Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Fri, Jan 8, 2010 at 12:38 AM, martinvz\n wrote:\n>\n>\n> Santi Béjar-2 wrote:\n>>\n>> Can you provide, at least, a graph of your history (ala git log\n>> --graph --oneline for example)? And plot also the reflog entries and\n>> all the important commits.\n>>\n>\n> $ git log --graph --format=%h --all\n> * 2038a46 # topic-2\n> * a7b93b2\n> * f2501ae # origin/main\n> * cd5aaa9\n> * cb232f3\n> ...\n> * 5ed0d06\n> * 3067862\n> | * 6eba2fa # topic-1\n> | * b09aaf4\n> | * bc3b72a\n> |/\n> | * 03d0d84 # topic-3\n> | * 5160773\n> | * 3c25642\n> |/\n> | * 6e9b12b # topic-4\n> | * 75f5ab2\n> | * bdd08ce\n> | * b5d5759\n> |/\n> * 486b580\n> * a021696\n> * 3ffe7df\n> * d0f55c5\n> ...\n>\n> I have topic-1 checked out and run \"git pull\" and expect it to rebase (only)\n> commits bc3b72a, b09aaf4, 6eba2fa onto f2501ae, but it starts by applying\n> a021696 and 486b580.\n>\n> $ git reflog -g origin/main\n> f2501ae refs/remotes/origin/mai  n@{0}: fetch origin: fast forward\n> 3ffe7df refs/remotes/origin/mai  n@{1}: fetch origin: fast forward\n> ...\n>\n> I hope that's all that's all you need. It seems that the problem is that the\n> oldremoteref gets overwritten with the entry from the reflog. Is the problem\n> that 3ffe7df appears in the reflog or that 486b580 doesn't appear there? I'm\n> not clear on what ends up in the reflog.\n>\n> I just realized that I myself created a021696 and 486b580 (but not 3ffe7df),\n> probably by rebasing some now-dead branch against origin/main.\n\nYes, it is. The code expects that you always branch your topic\nbranches from the upstream branch, so all the possible fork points are\nin the reflog. Your flow was to create the topic from a local commit\nand then push that commit.\n\nBy the way, when Git tries to apply these two commits it should detect\nthat they are already applied so it should do nothing, isn't it?\n\nHTH,\nSanti\n"},{"id":"131117","messageId":"1262979676402-4274470.post@n2.nabble.com","threadId":"22112","inReplyTo":"adf1fd3d1001080305k138a2670k17a126cc0b8430b8@mail.gmail.com","subject":"Re: Difference between pull --rebase and fetch+rebase","fromName":"martinvz","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-01-08T19:41:16Z","receivedAt":"2010-01-08T19:41:16Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"\n\nSanti Béjar-2 wrote:\n> \n> Yes, it is. The code expects that you always branch your topic\n> branches from the upstream branch, so all the possible fork points are\n> in the reflog. Your flow was to create the topic from a local commit\n> and then push that commit.\n> \n\nThanks, Santi! After thinking for a while about what you said, I think I\nunderstand. That could definitely be what I did, although I can't remember\nfor sure.\n\nWould it make sense to teach \"git rebase\" the same tricks as \"git pull\n--rebase\"?\n\n\nSanti Béjar-2 wrote:\n> \n> By the way, when Git tries to apply these two commits it should detect\n> that they are already applied so it should do nothing, isn't it?\n> \n\nAlmost - it fails, but the merge tool resolves it automatically.\n\n\nMartin\n-- \nView this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4274470.html\nSent from the git mailing list archive at Nabble.com.\n"}]}