Re: Bug report for pull --rebase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux