(With apologies to duplicate recipients; missed "Reply All") On Fri, May 9, 2025 at 1:59 PM Tuomas Ahola <taahol@xxxxxx> wrote: > > "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 I think I'm confused: are you suggesting that the merge-base output affects my bisection or is indicative of the cause of the failure? (Also note that I don't keep my fork's master/seen/etc. branches up to date very often.) -- D. Ben Knoble