git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Bug report for pull --rebase

From
D. Ben Knoble <ben.knoble@gmail.com>
Date
May 10, 2025, 19:21 UTC
Message-ID
<CALnO6CCqo5C-h_Lh7XrYinieXstgcddSTX70tTvLvhyVNTcdCA@mail.gmail.com>
In-Reply-To
<20250509175921.N7Sy9%taahol@utu.fi>
(With apologies to duplicate recipients; missed "Reply All")
On Fri, May 9, 2025 at 1:59 PM Tuomas Ahola <taahol@utu.fi> wrote:
Show 65 quoted lines
>
> "D. Ben Knoble" <ben.knoble@gmail.com> wrote:
>
> > On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@gmail.com> 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
Previous: Tuomas AholaNext: Torsten Bögershausen
Message 4 of 8 in “Bug report for pull --rebase”
  1. Mr BillMay 6, 2025
  2. D. Ben KnobleMay 9, 2025
  3. Tuomas AholaMay 9, 2025
  4. D. Ben KnobleMay 10, 2025
  5. Torsten BögershausenMay 10, 2025
  6. D. Ben KnobleMay 10, 2025
  7. Phillip WoodMay 12, 2025
  8. Mr BillMay 13, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.