{"thread":{"id":"63408","subject":"Bug report for pull --rebase","startedAt":"2025-05-06T21:36:48Z","lastAt":"2025-05-13T17:22:48Z","messageCount":8,"participants":["Mr Bill","D. Ben Knoble","Tuomas Ahola","Torsten Bögershausen","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"517394","messageId":"8c075e6e-c28c-4146-66bc-9bd7bc705611@gmail.com","threadId":"63408","inReplyTo":null,"subject":"Bug report for pull --rebase","fromName":"Mr Bill","fromEmail":"billc56196@gmail.com","sentAt":"2025-05-06T21:36:44Z","receivedAt":"2025-05-06T21:36:48Z","isPatch":false,"sender":{"key":"billc56196@gmail.com","avatar":null},"body":"\nHi, I ran across this doing a pull --rebase using the current master \nversion of git\n\nThis happens on Slackware linux, using git HEAD, version 2.35.8, and 2.46.2\n\nI have a clone of the ffmpeg video package, with a few custom commits on \ntop of it,\nI periodically fetch and \"pull --rebase\" to update the underlying ffmpeg \ncode.\nI tried this recently, and my custom commits disappeared.\n\n\nI looked further with a small test, and it looks like this is happening:\n\nThe setup:\n    \"base\" repo with a few commits (A, B, C)\n    \"clone_1\" cloned from \"base\", with a few extra commits (F, G)\n    \"clone_2\" cloned from \"clone_1\"\n\nAdd a few more commits for base (D, E)\n\nThen use \"git remote set-url origin\" to point \"clone_2\" to \"base\"\n\nThen, in \"clone_2\" do \"pull --rebase\"; the F and G commits disappear.\n\nThen, in \"clone_1\" do \"pull --rebase\"; the F and G commits are retained.\n\nSomething like this:\n\n# commit trees:\n#\n#    base: A---B---C          (initial base repo with 3 commits)\n# clone_1: A---B---C          (clone_1 cloned from base at commit C)\n#    base: A---B---C---D---E  (base added extra commits D and E)\n# clone_1: A---B---C---F---G  (clone_1 added extra commits F and G)\n# clone_2: A---B---C---F---G  (clone_2 cloned from clone_1 at commit G)\n#\n# *** now, change clone_2 to use base as the upstream url, and fetch / \npull / rebase to get up to date ***\n#\n# * set clone_2 upstream to point to base repo\n# * \"pull --rebase\" in clone_2 (should fetch from base repo and rebase F \nand G after D and E)\n#\n#   expected result: A---B---C---D---E---F---G\n#   actual result:   A---B---C---D---E\n#   commits F and G are gone\n#\n# Doing \"pull --rebase\" in clone_1 gives the expected result:\n#   expected result: A---B---C---D---E---F---G\n#\n\nThis looks like either stale state info after the \"set-url\" command,\nor I'm doing something wrong.\n\nI can repeatedly cause this to happen in my local ffmpeg devel area, if \nthat helps debug/test this.\n... and answer questions, if any.\n\nThanks for the help!\nBill\n\nP.S. here's the test script I used for this:\n\n--------------------------------------------------------------------------\n\n#!/bin/bash\n\nset -o errexit\n\nBASE_WORKING_DIR=\"rebase_bug.working\"\n\n# Clean up the test area\nrm -rf \"${BASE_WORKING_DIR:?}\"\nmkdir  \"${BASE_WORKING_DIR:?}\"\ncd     \"${BASE_WORKING_DIR:?}\"\n\nWORKING_DIR=\"${PWD}\"\n\nmkdir test_rebase_base.git\ncd test_rebase_base.git\n\n     # create the base git repo, with commit A, B and C\n     git init\n     echo \"Commit A\" > testfileA\n     git add testfileA\n     git commit -m \"Commit A\"\n\n     echo \"Commit B\" > testfileB\n     git add testfileB\n     git commit -m \"Commit B\"\n\n     echo \"Commit C\" > testfileC\n     git add testfileC\n     git commit -m \"Commit C\"\n\ncd ..\n\n     # Clone the base area into the clone_1 area\n     git clone test_rebase_base.git test_rebase_clone_1.git\n\ncd test_rebase_base.git\n     # Add commit D and E to the base area\n\n     echo \"Commit D\" > testfileD\n     git add testfileD\n     git commit -m \"Commit D\"\n\n     echo \"Commit E\" > testfileE\n     git add testfileE\n     git commit -m \"Commit E\"\n\ncd ..\n\ncd test_rebase_clone_1.git\n     # Add commit F and G to the clone_1 area\n\n     echo \"Commit F\" > testfileF\n     git add testfileF\n     git commit -m \"Commit F\"\n\n     echo \"Commit G\" > testfileG\n     git add testfileG\n     git commit -m \"Commit G\"\n\ncd ..\n\n     # clone from clone_1 into clone_2\n     git clone test_rebase_clone_1.git test_rebase_clone_2.git\n\ncd test_rebase_clone_2.git\n\n     # change clone_2 to point to base\n\n     git remote set-url origin \"${WORKING_DIR:?}/test_rebase_base.git\"\n\n     # expecting this to pull in the \"base\" extra commits, and move the \nlocal HEAD commit after it in sequence\n     git pull --rebase\n\ncd ..\n\ncd test_rebase_clone_1.git\n     # do the same pull --rebase in clone_1\n     git pull --rebase\n\ncd ..\n\ncd test_rebase_base.git\ngit log --oneline > \"${WORKING_DIR:?}/test_rebase_base.oneline.log\"\ncd ..\n\ncd test_rebase_clone_1.git\ngit log --oneline > \"${WORKING_DIR:?}/test_rebase_clone_1.oneline.log\"\ncd ..\n\ncd test_rebase_clone_2.git\ngit log --oneline > \"${WORKING_DIR:?}/test_rebase_clone_2.oneline.log\"\ncd ..\n\n# The test_rebase_clone_1.oneline.log and \ntest_rebase_clone_2.oneline.log should match, but they don't\n\necho \"done\"\n\n--------------------------------------------------------------------------------------------------\n"},{"id":"517697","messageId":"CALnO6CB6aH5DEDP3QL43RCFfaZJ3uzrAY1LdGyTNi8F3XVoEhw@mail.gmail.com","threadId":"63408","inReplyTo":"8c075e6e-c28c-4146-66bc-9bd7bc705611@gmail.com","subject":"Re: Bug report for pull --rebase","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-05-09T16:41:47Z","receivedAt":"2025-05-09T16:42:00Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@gmail.com> wrote:\n>\n>\n> Hi, I ran across this doing a pull --rebase using the current master\n> version of git\n>\n> This happens on Slackware linux, using git HEAD, version 2.35.8, and 2.46.2\n>\n> I have a clone of the ffmpeg video package, with a few custom commits on\n> top of it,\n> I periodically fetch and \"pull --rebase\" to update the underlying ffmpeg\n> code.\n> I tried this recently, and my custom commits disappeared.\n>\n>\n> I looked further with a small test, and it looks like this is happening:\n>\n> The setup:\n>     \"base\" repo with a few commits (A, B, C)\n>     \"clone_1\" cloned from \"base\", with a few extra commits (F, G)\n>     \"clone_2\" cloned from \"clone_1\"\n>\n> Add a few more commits for base (D, E)\n>\n> Then use \"git remote set-url origin\" to point \"clone_2\" to \"base\"\n>\n> Then, in \"clone_2\" do \"pull --rebase\"; the F and G commits disappear.\n>\n> Then, in \"clone_1\" do \"pull --rebase\"; the F and G commits are retained.\n\nThanks for including a script! I modified it (uploaded to\nhttps://gist.github.com/benknoble/7a5eecd522b48669c2a5207e2ed9b7ee to\navoid problems with my mailer) to be suitable for use with bisect.\n\nI put the script at /tmp/bugreport/doit next to a clone of the Git\nsource code, then (in the Git source repo) started a --first-parent\nbisect between 2.49 and 2.0 with the ../doit script as the runner;\nhere's the log:\n\n# bad: [683c54c999c301c2cd6f715c411407c413b1d84e] Git 2.49\n# good: [e156455ea49124c140a67623f22a393db62d5d98] Git 2.0\ngit bisect start '--first-parent' '@' 'v2.0.0'\n# bad: [4336fdb2efaf77b720f152c06b5ce2aa2e347fb6] Merge branch\n'rs/nedalloc-fixlets'\ngit bisect bad 4336fdb2efaf77b720f152c06b5ce2aa2e347fb6\n# bad: [130b664e442767587638b3e807a6f543168239d7] Merge branch\n'js/travis-32bit-linux'\ngit bisect bad 130b664e442767587638b3e807a6f543168239d7\n# bad: [922239e7da03f8e0a8c6ba809c1ee0cf3776f94a] Merge branch\n'dk/p4-import-ctypes'\ngit bisect bad 922239e7da03f8e0a8c6ba809c1ee0cf3776f94a\n# bad: [afa3ccbf44cb47cf988c6f40ce3ddb10829a9e7b] Merge branch\n'jc/pretty-format-doc'\ngit bisect bad afa3ccbf44cb47cf988c6f40ce3ddb10829a9e7b\n# bad: [7669461459aaee1587bac77c4a446e9365b582c7] Merge branch\n'rs/merge-tree-simplify'\ngit bisect bad 7669461459aaee1587bac77c4a446e9365b582c7\n# bad: [3d77f72efe79eb90f67aec9ecf6d4bd11fc9a78c] Merge branch\n'jc/fix-clone-single-starting-at-a-tag'\ngit bisect bad 3d77f72efe79eb90f67aec9ecf6d4bd11fc9a78c\n# bad: [5b3a58d459171f49ee8d486e4ac399eb2678605d] Merge branch\n'jk/argv-array-for-child-process'\ngit bisect bad 5b3a58d459171f49ee8d486e4ac399eb2678605d\n# bad: [d83c9c75e1edebd4ece3ad5223103f46fc38a4d3] Merge branch\n'jk/grep-tell-run-command-to-cd-when-running-pager'\ngit bisect bad d83c9c75e1edebd4ece3ad5223103f46fc38a4d3\n# bad: [e3798318b12502ae13a8e35e4a385665e810047f] Merge branch\n'mm/mediawiki-encoding-fix'\ngit bisect bad e3798318b12502ae13a8e35e4a385665e810047f\n# bad: [2e4b5dee97cb1524a88f0ee90450b139bfaff07b] Merge branch\n'rs/ref-update-check-errors-early'\ngit bisect bad 2e4b5dee97cb1524a88f0ee90450b139bfaff07b\n# bad: [f008cef4abb2a4db766b4a152b304aca91a0101a] Merge branch\n'jc/apply-ignore-whitespace'\ngit bisect bad f008cef4abb2a4db766b4a152b304aca91a0101a\n# bad: [bce14aa132e0064d9a9b1c7ad98e71e22c6e0272] Sync with 1.9.4\ngit bisect bad bce14aa132e0064d9a9b1c7ad98e71e22c6e0272\n# bad: [d7172825321369cb951dd7bbfc0c12dc4ecbe518] t5537: re-drop http tests\ngit bisect bad d7172825321369cb951dd7bbfc0c12dc4ecbe518\n# first bad commit: [d7172825321369cb951dd7bbfc0c12dc4ecbe518] t5537:\nre-drop http tests\n\nI think this just means the bug has been present since at least 2.0 (I\nnever checked if 2.0 was actually \"good\"; that was just as far back as\nI was willing to go).\n\nI didn't try to track down where it came from, though.\n\nP.S. I was having trouble building master (something in the linker\nwith _false_but_the_compiler_does_not_know_it)? Revision 1ee85f0e21\n(The twelfth batch, 2025-05-08). Log at\nhttps://gist.github.com/benknoble/a8bdc272f44673e115f8b3e57d62e4f6.\nP.P.S. I was flummoxed for a long time before I realized that \"git\nbisect run\" sets GIT_DIR in the environment (checked by comparing the\nscript's environment in and out of \"git bisect run\"); is that\ndocumented? Intended? Made it harder to drive Git in this script (see\n\"unset GIT_DIR\").\n\n-- \nD. Ben Knoble\n"},{"id":"517703","messageId":"20250509175921.N7Sy9%taahol@utu.fi","threadId":"63408","inReplyTo":"CALnO6CB6aH5DEDP3QL43RCFfaZJ3uzrAY1LdGyTNi8F3XVoEhw@mail.gmail.com","subject":"Re: Bug report for pull --rebase","fromName":"Tuomas Ahola","fromEmail":"taahol@utu.fi","sentAt":"2025-05-09T17:59:21Z","receivedAt":"2025-05-09T18:14:36Z","isPatch":false,"sender":{"key":"taahol@utu.fi","avatar":"https://avatars.githubusercontent.com/u/114303477?v=4"},"body":"\"D. Ben Knoble\" <ben.knoble@gmail.com> wrote:\n\n> On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@gmail.com> wrote:\n> >\n> >\n> > Hi, I ran across this doing a pull --rebase using the current master\n> > version of git\n> >\n> > This happens on Slackware linux, using git HEAD, version 2.35.8, and 2.46.2\n> >\n> > I have a clone of the ffmpeg video package, with a few custom commits on\n> > top of it,\n> > I periodically fetch and \"pull --rebase\" to update the underlying ffmpeg\n> > code.\n> > I tried this recently, and my custom commits disappeared.\n> >\n> >\n> > I looked further with a small test, and it looks like this is happening:\n> >\n> > The setup:\n> >     \"base\" repo with a few commits (A, B, C)\n> >     \"clone_1\" cloned from \"base\", with a few extra commits (F, G)\n> >     \"clone_2\" cloned from \"clone_1\"\n> >\n> > Add a few more commits for base (D, E)\n> >\n> > Then use \"git remote set-url origin\" to point \"clone_2\" to \"base\"\n> >\n> > Then, in \"clone_2\" do \"pull --rebase\"; the F and G commits disappear.\n> >\n> > Then, in \"clone_1\" do \"pull --rebase\"; the F and G commits are retained.\n> \n> Thanks for including a script! I modified it (uploaded to\n> https://gist.github.com/benknoble/7a5eecd522b48669c2a5207e2ed9b7ee to\n> avoid problems with my mailer) to be suitable for use with bisect.\n> \n> I put the script at /tmp/bugreport/doit next to a clone of the Git\n> source code, then (in the Git source repo) started a --first-parent\n> bisect between 2.49 and 2.0 with the ../doit script as the runner;\n\nHello!\n\nI think I found something related.  Let’s test on your Git fork:\n\n```\n$ git clone https://github.com/benknoble/git.git git && cd git\n$ git checkout next\n$ git remote set-url origin \"https://github.com/git/git.git\"\n$ git remote add upstream \"https://github.com/git/git.git\"\n$ git fetch origin next\n$ git fetch upstream next\n```\n\nNow these yield different results:\n\n```\n$ git merge-base --fork-point origin/next @\ne0522318ac56aeb88f14e72ba2db25912e9972de\n$ git merge-base --fork-point upstream/next @\n```\n\nWhich looks like a bug to me.\n-- \nTuomas Ahola\n"},{"id":"517726","messageId":"20250510081005.GA4318@tb-raspi4","threadId":"63408","inReplyTo":"CALnO6CB6aH5DEDP3QL43RCFfaZJ3uzrAY1LdGyTNi8F3XVoEhw@mail.gmail.com","subject":"Re: Bug report for pull --rebase","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2025-05-10T08:10:05Z","receivedAt":"2025-05-10T08:34:52Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Fri, May 09, 2025 at 12:41:47PM -0400, D. Ben Knoble wrote:\n> On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@gmail.com> wrote:\n[]\n\n> P.S. I was having trouble building master (something in the linker\n> with _false_but_the_compiler_does_not_know_it)? Revision 1ee85f0e21\n> (The twelfth batch, 2025-05-08). Log at\n\nThis has been fixed the last days.\nThe fix works under MacOs,\ndo you think that you can test the patch, please ?\n<https://github.com/gitster/git/tree/tb/macos-false-but-the-compiler-does-not-know-it-fix>\n\nOr look into the seen branch.\n"},{"id":"517756","messageId":"CALnO6CCqo5C-h_Lh7XrYinieXstgcddSTX70tTvLvhyVNTcdCA@mail.gmail.com","threadId":"63408","inReplyTo":"20250509175921.N7Sy9%taahol@utu.fi","subject":"Re: Bug report for pull --rebase","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-05-10T19:21:51Z","receivedAt":"2025-05-10T19:22:04Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"(With apologies to duplicate recipients; missed \"Reply All\")\n\nOn Fri, May 9, 2025 at 1:59 PM Tuomas Ahola <taahol@utu.fi> wrote:\n>\n> \"D. Ben Knoble\" <ben.knoble@gmail.com> wrote:\n>\n> > On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@gmail.com> wrote:\n> > >\n> > >\n> > > Hi, I ran across this doing a pull --rebase using the current master\n> > > version of git\n> > >\n> > > This happens on Slackware linux, using git HEAD, version 2.35.8, and 2.46.2\n> > >\n> > > I have a clone of the ffmpeg video package, with a few custom commits on\n> > > top of it,\n> > > I periodically fetch and \"pull --rebase\" to update the underlying ffmpeg\n> > > code.\n> > > I tried this recently, and my custom commits disappeared.\n> > >\n> > >\n> > > I looked further with a small test, and it looks like this is happening:\n> > >\n> > > The setup:\n> > >     \"base\" repo with a few commits (A, B, C)\n> > >     \"clone_1\" cloned from \"base\", with a few extra commits (F, G)\n> > >     \"clone_2\" cloned from \"clone_1\"\n> > >\n> > > Add a few more commits for base (D, E)\n> > >\n> > > Then use \"git remote set-url origin\" to point \"clone_2\" to \"base\"\n> > >\n> > > Then, in \"clone_2\" do \"pull --rebase\"; the F and G commits disappear.\n> > >\n> > > Then, in \"clone_1\" do \"pull --rebase\"; the F and G commits are retained.\n> >\n> > Thanks for including a script! I modified it (uploaded to\n> > https://gist.github.com/benknoble/7a5eecd522b48669c2a5207e2ed9b7ee to\n> > avoid problems with my mailer) to be suitable for use with bisect.\n> >\n> > I put the script at /tmp/bugreport/doit next to a clone of the Git\n> > source code, then (in the Git source repo) started a --first-parent\n> > bisect between 2.49 and 2.0 with the ../doit script as the runner;\n>\n> Hello!\n>\n> I think I found something related.  Let’s test on your Git fork:\n>\n> ```\n> $ git clone https://github.com/benknoble/git.git git && cd git\n> $ git checkout next\n> $ git remote set-url origin \"https://github.com/git/git.git\"\n> $ git remote add upstream \"https://github.com/git/git.git\"\n> $ git fetch origin next\n> $ git fetch upstream next\n> ```\n>\n> Now these yield different results:\n>\n> ```\n> $ git merge-base --fork-point origin/next @\n> e0522318ac56aeb88f14e72ba2db25912e9972de\n> $ git merge-base --fork-point upstream/next @\n> ```\n>\n> Which looks like a bug to me.\n> --\n> Tuomas Ahola\n\nI think I'm confused: are you suggesting that the merge-base output\naffects my bisection or is indicative of the cause of the failure?\n\n(Also note that I don't keep my fork's master/seen/etc. branches up to\ndate very often.)\n\n-- \nD. Ben Knoble\n"},{"id":"517757","messageId":"CALnO6CCuTa24gJTPfp-1e1Y7=1wV=+rq9098xBoW0=ZkGcbgKA@mail.gmail.com","threadId":"63408","inReplyTo":"20250510081005.GA4318@tb-raspi4","subject":"Re: Bug report for pull --rebase","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-05-10T19:22:22Z","receivedAt":"2025-05-10T19:22:34Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Sat, May 10, 2025 at 4:10 AM Torsten Bögershausen <tboegi@web.de> wrote:\n>\n> On Fri, May 09, 2025 at 12:41:47PM -0400, D. Ben Knoble wrote:\n> > On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@gmail.com> wrote:\n> []\n>\n> > P.S. I was having trouble building master (something in the linker\n> > with _false_but_the_compiler_does_not_know_it)? Revision 1ee85f0e21\n> > (The twelfth batch, 2025-05-08). Log at\n>\n> This has been fixed the last days.\n> The fix works under MacOs,\n> do you think that you can test the patch, please ?\n> <https://github.com/gitster/git/tree/tb/macos-false-but-the-compiler-does-not-know-it-fix>\n>\n> Or look into the seen branch.\n\nIndeed; a recent (unrelated) build off of the tip of master worked\njust fine. Thanks!\n\n-- \nD. Ben Knoble\n"},{"id":"517848","messageId":"6bebcee9-1315-4ec3-a49b-d767f0f67bf7@gmail.com","threadId":"63408","inReplyTo":"8c075e6e-c28c-4146-66bc-9bd7bc705611@gmail.com","subject":"Re: Bug report for pull --rebase","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2025-05-12T14:07:46Z","receivedAt":"2025-05-12T14:07:50Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 06/05/2025 22:36, Mr Bill wrote:\n> \n> Hi, I ran across this doing a pull --rebase using the current master version of git\n> \n> This happens on Slackware linux, using git HEAD, version 2.35.8, and 2.46.2\n> \n> I have a clone of the ffmpeg video package, with a few custom commits on top of it,\n> I periodically fetch and \"pull --rebase\" to update the underlying ffmpeg code.\n> I tried this recently, and my custom commits disappeared.\n> \n> \n> I looked further with a small test, and it looks like this is happening:\n> \n> The setup:\n>     \"base\" repo with a few commits (A, B, C)\n>     \"clone_1\" cloned from \"base\", with a few extra commits (F, G)\n>     \"clone_2\" cloned from \"clone_1\"\n> \n> Add a few more commits for base (D, E)\n> \n> Then use \"git remote set-url origin\" to point \"clone_2\" to \"base\"\n> \n> Then, in \"clone_2\" do \"pull --rebase\"; the F and G commits disappear.\n\nAfter the url is updated the reflog for the upstream branch still has\nan entry for \"G\". When \"git pull --rebase\" runs \"git merge-base\n--fork-point <upstream-branch> HEAD\" it will return \"G\" and so that\ncommit will be excluded from the commits being rebased. Running\n\n   git fetch && git rebase --no-fork-point\n\nshould keep the commits \"F\" and \"G\". Alternatively instead of updating\nthe url you could rename the \"origin\" remote and then add a new remote\ncalled \"origin\" pointing to base. That way when you pull the reflog\nfor the upstream branch will not have entries from the previous\nremote url.\n\n> Then, in \"clone_1\" do \"pull --rebase\"; the F and G commits are retained.\n\nThat's because \"F\" and \"G\" are not in the reflog of the upstream branch\nin clone_1.\n\nIt's debatable whether \"git pull --rebase\" should use \"--fork-point\" by\ndefault. On the one hand it is convenient when the history of the\nupstream branch has been rewritten but on the other hand it leads to\nunexpected surprises like this. The fact that there isn't a way to\ndisable it and it ignores the rebase.forkPoint config setting does not\nhelp.\n\nBest Wishes\n\nPhillip\n\n\n> Something like this:\n> \n> # commit trees:\n> #\n> #    base: A---B---C          (initial base repo with 3 commits)\n> # clone_1: A---B---C          (clone_1 cloned from base at commit C)\n> #    base: A---B---C---D---E  (base added extra commits D and E)\n> # clone_1: A---B---C---F---G  (clone_1 added extra commits F and G)\n> # clone_2: A---B---C---F---G  (clone_2 cloned from clone_1 at commit G)\n> #\n> # *** now, change clone_2 to use base as the upstream url, and fetch / pull / rebase to get up to date ***\n> #\n> # * set clone_2 upstream to point to base repo\n> # * \"pull --rebase\" in clone_2 (should fetch from base repo and rebase F and G after D and E)\n> #\n> #   expected result: A---B---C---D---E---F---G\n> #   actual result:   A---B---C---D---E\n> #   commits F and G are gone\n> #\n> # Doing \"pull --rebase\" in clone_1 gives the expected result:\n> #   expected result: A---B---C---D---E---F---G\n> #\n> \n> This looks like either stale state info after the \"set-url\" command,\n> or I'm doing something wrong.\n> \n> I can repeatedly cause this to happen in my local ffmpeg devel area, if that helps debug/test this.\n> ... and answer questions, if any.\n> \n> Thanks for the help!\n> Bill\n> \n> P.S. here's the test script I used for this:\n> \n> --------------------------------------------------------------------------\n> \n> #!/bin/bash\n> \n> set -o errexit\n> \n> BASE_WORKING_DIR=\"rebase_bug.working\"\n> \n> # Clean up the test area\n> rm -rf \"${BASE_WORKING_DIR:?}\"\n> mkdir  \"${BASE_WORKING_DIR:?}\"\n> cd     \"${BASE_WORKING_DIR:?}\"\n> \n> WORKING_DIR=\"${PWD}\"\n> \n> mkdir test_rebase_base.git\n> cd test_rebase_base.git\n> \n>      # create the base git repo, with commit A, B and C\n>      git init\n>      echo \"Commit A\" > testfileA\n>      git add testfileA\n>      git commit -m \"Commit A\"\n> \n>      echo \"Commit B\" > testfileB\n>      git add testfileB\n>      git commit -m \"Commit B\"\n> \n>      echo \"Commit C\" > testfileC\n>      git add testfileC\n>      git commit -m \"Commit C\"\n> \n> cd ..\n> \n>      # Clone the base area into the clone_1 area\n>      git clone test_rebase_base.git test_rebase_clone_1.git\n> \n> cd test_rebase_base.git\n>      # Add commit D and E to the base area\n> \n>      echo \"Commit D\" > testfileD\n>      git add testfileD\n>      git commit -m \"Commit D\"\n> \n>      echo \"Commit E\" > testfileE\n>      git add testfileE\n>      git commit -m \"Commit E\"\n> \n> cd ..\n> \n> cd test_rebase_clone_1.git\n>      # Add commit F and G to the clone_1 area\n> \n>      echo \"Commit F\" > testfileF\n>      git add testfileF\n>      git commit -m \"Commit F\"\n> \n>      echo \"Commit G\" > testfileG\n>      git add testfileG\n>      git commit -m \"Commit G\"\n> \n> cd ..\n> \n>      # clone from clone_1 into clone_2\n>      git clone test_rebase_clone_1.git test_rebase_clone_2.git\n> \n> cd test_rebase_clone_2.git\n> \n>      # change clone_2 to point to base\n> \n>      git remote set-url origin \"${WORKING_DIR:?}/test_rebase_base.git\"\n> \n>      # expecting this to pull in the \"base\" extra commits, and move the local HEAD commit after it in sequence\n>      git pull --rebase\n> \n> cd ..\n> \n> cd test_rebase_clone_1.git\n>      # do the same pull --rebase in clone_1\n>      git pull --rebase\n> \n> cd ..\n> \n> cd test_rebase_base.git\n> git log --oneline > \"${WORKING_DIR:?}/test_rebase_base.oneline.log\"\n> cd ..\n> \n> cd test_rebase_clone_1.git\n> git log --oneline > \"${WORKING_DIR:?}/test_rebase_clone_1.oneline.log\"\n> cd ..\n> \n> cd test_rebase_clone_2.git\n> git log --oneline > \"${WORKING_DIR:?}/test_rebase_clone_2.oneline.log\"\n> cd ..\n> \n> # The test_rebase_clone_1.oneline.log and test_rebase_clone_2.oneline.log should match, but they don't\n> \n> echo \"done\"\n> \n> --------------------------------------------------------------------------------------------------\n> \n"},{"id":"517958","messageId":"06c4f0b7-c314-59e0-5a05-a9d9a8369b30@gmail.com","threadId":"63408","inReplyTo":"6bebcee9-1315-4ec3-a49b-d767f0f67bf7@gmail.com","subject":"Re: Bug report for pull --rebase","fromName":"Mr Bill","fromEmail":"billc56196@gmail.com","sentAt":"2025-05-13T17:22:43Z","receivedAt":"2025-05-13T17:22:48Z","isPatch":false,"sender":{"key":"billc56196@gmail.com","avatar":null},"body":"On 05/12/2025 09:07 AM, Phillip Wood wrote:\n> On 06/05/2025 22:36, Mr Bill wrote:\n>>\n>> Hi, I ran across this doing a pull --rebase using the current master \n>> version of git\n>>\n>> This happens on Slackware linux, using git HEAD, version 2.35.8, and \n>> 2.46.2\n>>\n>> I have a clone of the ffmpeg video package, with a few custom commits \n>> on top of it,\n>> I periodically fetch and \"pull --rebase\" to update the underlying \n>> ffmpeg code.\n>> I tried this recently, and my custom commits disappeared.\n>>\n>>\n>> I looked further with a small test, and it looks like this is happening:\n>>\n>> The setup:\n>>     \"base\" repo with a few commits (A, B, C)\n>>     \"clone_1\" cloned from \"base\", with a few extra commits (F, G)\n>>     \"clone_2\" cloned from \"clone_1\"\n>>\n>> Add a few more commits for base (D, E)\n>>\n>> Then use \"git remote set-url origin\" to point \"clone_2\" to \"base\"\n>>\n>> Then, in \"clone_2\" do \"pull --rebase\"; the F and G commits disappear.\n>\n> After the url is updated the reflog for the upstream branch still has\n> an entry for \"G\". When \"git pull --rebase\" runs \"git merge-base\n> --fork-point <upstream-branch> HEAD\" it will return \"G\" and so that\n> commit will be excluded from the commits being rebased.\n\nThank you for your comments on this (Ben and Tuomas, also)\n\nI've seen this situation when looking at this issue.\n\nRunning \"git merge-base --fork-point...\" returns different values for\nthe clone_1 and clone_2 branches:\n* clone_1 points to commit \"C\"\n* clone_2 points to commit \"G\"\n\n... apparently because of the extra \"G\" entry for the upstream branch.\n\nI was expecting running \"git fetch\" after the \"git remote set-url...\" would\nupdate the upstream HEAD information to reflect the new upstream repo state.\n(and \"git fetch\" happens as part of \"git pull --rebase\", so that's \ncovered, too)\n\nIn my case, I can use the \"rebase --no-fork-point\" style to keep my updates.\n\nThanks again!\n- Bill\n\n> Running\n>\n>   git fetch && git rebase --no-fork-point\n>\n> should keep the commits \"F\" and \"G\". Alternatively instead of updating\n> the url you could rename the \"origin\" remote and then add a new remote\n> called \"origin\" pointing to base. That way when you pull the reflog\n> for the upstream branch will not have entries from the previous\n> remote url.\n>\n>> Then, in \"clone_1\" do \"pull --rebase\"; the F and G commits are retained.\n>\n> That's because \"F\" and \"G\" are not in the reflog of the upstream branch\n> in clone_1.\n>\n> It's debatable whether \"git pull --rebase\" should use \"--fork-point\" by\n> default. On the one hand it is convenient when the history of the\n> upstream branch has been rewritten but on the other hand it leads to\n> unexpected surprises like this. The fact that there isn't a way to\n> disable it and it ignores the rebase.forkPoint config setting does not\n> help.\n>\n> Best Wishes\n>\n> Phillip\n>\n>\n>> Something like this:\n>>\n>> # commit trees:\n>> #\n>> #    base: A---B---C          (initial base repo with 3 commits)\n>> # clone_1: A---B---C          (clone_1 cloned from base at commit C)\n>> #    base: A---B---C---D---E  (base added extra commits D and E)\n>> # clone_1: A---B---C---F---G  (clone_1 added extra commits F and G)\n>> # clone_2: A---B---C---F---G  (clone_2 cloned from clone_1 at commit G)\n>> #\n>> # *** now, change clone_2 to use base as the upstream url, and fetch \n>> / pull / rebase to get up to date ***\n>> #\n>> # * set clone_2 upstream to point to base repo\n>> # * \"pull --rebase\" in clone_2 (should fetch from base repo and \n>> rebase F and G after D and E)\n>> #\n>> #   expected result: A---B---C---D---E---F---G\n>> #   actual result:   A---B---C---D---E\n>> #   commits F and G are gone\n>> #\n>> # Doing \"pull --rebase\" in clone_1 gives the expected result:\n>> #   expected result: A---B---C---D---E---F---G\n>> #\n>>\n>> This looks like either stale state info after the \"set-url\" command,\n>> or I'm doing something wrong.\n>>\n>> I can repeatedly cause this to happen in my local ffmpeg devel area, \n>> if that helps debug/test this.\n>> ... and answer questions, if any.\n>>\n>> Thanks for the help!\n>> Bill\n>>\n>> P.S. here's the test script I used for this:\n>>\n>> -------------------------------------------------------------------------- \n>>\n>>\n>> #!/bin/bash\n>>\n>> set -o errexit\n>>\n>> BASE_WORKING_DIR=\"rebase_bug.working\"\n>>\n>> # Clean up the test area\n>> rm -rf \"${BASE_WORKING_DIR:?}\"\n>> mkdir  \"${BASE_WORKING_DIR:?}\"\n>> cd     \"${BASE_WORKING_DIR:?}\"\n>>\n>> WORKING_DIR=\"${PWD}\"\n>>\n>> mkdir test_rebase_base.git\n>> cd test_rebase_base.git\n>>\n>>      # create the base git repo, with commit A, B and C\n>>      git init\n>>      echo \"Commit A\" > testfileA\n>>      git add testfileA\n>>      git commit -m \"Commit A\"\n>>\n>>      echo \"Commit B\" > testfileB\n>>      git add testfileB\n>>      git commit -m \"Commit B\"\n>>\n>>      echo \"Commit C\" > testfileC\n>>      git add testfileC\n>>      git commit -m \"Commit C\"\n>>\n>> cd ..\n>>\n>>      # Clone the base area into the clone_1 area\n>>      git clone test_rebase_base.git test_rebase_clone_1.git\n>>\n>> cd test_rebase_base.git\n>>      # Add commit D and E to the base area\n>>\n>>      echo \"Commit D\" > testfileD\n>>      git add testfileD\n>>      git commit -m \"Commit D\"\n>>\n>>      echo \"Commit E\" > testfileE\n>>      git add testfileE\n>>      git commit -m \"Commit E\"\n>>\n>> cd ..\n>>\n>> cd test_rebase_clone_1.git\n>>      # Add commit F and G to the clone_1 area\n>>\n>>      echo \"Commit F\" > testfileF\n>>      git add testfileF\n>>      git commit -m \"Commit F\"\n>>\n>>      echo \"Commit G\" > testfileG\n>>      git add testfileG\n>>      git commit -m \"Commit G\"\n>>\n>> cd ..\n>>\n>>      # clone from clone_1 into clone_2\n>>      git clone test_rebase_clone_1.git test_rebase_clone_2.git\n>>\n>> cd test_rebase_clone_2.git\n>>\n>>      # change clone_2 to point to base\n>>\n>>      git remote set-url origin \"${WORKING_DIR:?}/test_rebase_base.git\"\n>>\n>>      # expecting this to pull in the \"base\" extra commits, and move \n>> the local HEAD commit after it in sequence\n>>      git pull --rebase\n>>\n>> cd ..\n>>\n>> cd test_rebase_clone_1.git\n>>      # do the same pull --rebase in clone_1\n>>      git pull --rebase\n>>\n>> cd ..\n>>\n>> cd test_rebase_base.git\n>> git log --oneline > \"${WORKING_DIR:?}/test_rebase_base.oneline.log\"\n>> cd ..\n>>\n>> cd test_rebase_clone_1.git\n>> git log --oneline > \"${WORKING_DIR:?}/test_rebase_clone_1.oneline.log\"\n>> cd ..\n>>\n>> cd test_rebase_clone_2.git\n>> git log --oneline > \"${WORKING_DIR:?}/test_rebase_clone_2.oneline.log\"\n>> cd ..\n>>\n>> # The test_rebase_clone_1.oneline.log and \n>> test_rebase_clone_2.oneline.log should match, but they don't\n>>\n>> echo \"done\"\n>>\n>> -------------------------------------------------------------------------------------------------- \n>>\n>>\n>\n\n"}]}