"D. Ben Knoble" <ben.knoble@xxxxxxxxx> wrote: > On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@xxxxxxxxx> wrote: > > > > > > Hi, I ran across this doing a pull --rebase using the current master > > version of git > > > > This happens on Slackware linux, using git HEAD, version 2.35.8, and 2.46.2 > > > > I have a clone of the ffmpeg video package, with a few custom commits on > > top of it, > > I periodically fetch and "pull --rebase" to update the underlying ffmpeg > > code. > > I tried this recently, and my custom commits disappeared. > > > > > > I looked further with a small test, and it looks like this is happening: > > > > The setup: > > "base" repo with a few commits (A, B, C) > > "clone_1" cloned from "base", with a few extra commits (F, G) > > "clone_2" cloned from "clone_1" > > > > Add a few more commits for base (D, E) > > > > Then use "git remote set-url origin" to point "clone_2" to "base" > > > > Then, in "clone_2" do "pull --rebase"; the F and G commits disappear. > > > > Then, in "clone_1" do "pull --rebase"; the F and G commits are retained. > > Thanks for including a script! I modified it (uploaded to > https://gist.github.com/benknoble/7a5eecd522b48669c2a5207e2ed9b7ee to > avoid problems with my mailer) to be suitable for use with bisect. > > I put the script at /tmp/bugreport/doit next to a clone of the Git > source code, then (in the Git source repo) started a --first-parent > bisect between 2.49 and 2.0 with the ../doit script as the runner; Hello! I think I found something related. Let’s test on your Git fork: ``` $ git clone https://github.com/benknoble/git.git git && cd git $ git checkout next $ git remote set-url origin "https://github.com/git/git.git"; $ git remote add upstream "https://github.com/git/git.git"; $ git fetch origin next $ git fetch upstream next ``` Now these yield different results: ``` $ git merge-base --fork-point origin/next @ e0522318ac56aeb88f14e72ba2db25912e9972de $ git merge-base --fork-point upstream/next @ ``` Which looks like a bug to me. -- Tuomas Ahola
