Bug report for pull --rebase

Bug report for pull --rebase

[Mr Bill]

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.

Something like this:

# commit trees:
#
#    base: A---B---C          (initial base repo with 3 commits)
# clone_1: A---B---C          (clone_1 cloned from base at commit C)
#    base: A---B---C---D---E  (base added extra commits D and E)
# clone_1: A---B---C---F---G  (clone_1 added extra commits F and G)
# clone_2: A---B---C---F---G  (clone_2 cloned from clone_1 at commit G)
#
# *** now, change clone_2 to use base as the upstream url, and fetch / 
pull / rebase to get up to date ***
#
# * set clone_2 upstream to point to base repo
# * "pull --rebase" in clone_2 (should fetch from base repo and rebase F 
and G after D and E)
#
#   expected result: A---B---C---D---E---F---G
#   actual result:   A---B---C---D---E
#   commits F and G are gone
#
# Doing "pull --rebase" in clone_1 gives the expected result:
#   expected result: A---B---C---D---E---F---G
#

This looks like either stale state info after the "set-url" command,
or I'm doing something wrong.

I can repeatedly cause this to happen in my local ffmpeg devel area, if 
that helps debug/test this.
... and answer questions, if any.

Thanks for the help!
Bill

P.S. here's the test script I used for this:

--------------------------------------------------------------------------

#!/bin/bash

set -o errexit

BASE_WORKING_DIR="rebase_bug.working"

# Clean up the test area
rm -rf "${BASE_WORKING_DIR:?}"
mkdir  "${BASE_WORKING_DIR:?}"
cd     "${BASE_WORKING_DIR:?}"

WORKING_DIR="${PWD}"

mkdir test_rebase_base.git
cd test_rebase_base.git

     # create the base git repo, with commit A, B and C
     git init
     echo "Commit A" > testfileA
     git add testfileA
     git commit -m "Commit A"

     echo "Commit B" > testfileB
     git add testfileB
     git commit -m "Commit B"

     echo "Commit C" > testfileC
     git add testfileC
     git commit -m "Commit C"

cd ..

     # Clone the base area into the clone_1 area
     git clone test_rebase_base.git test_rebase_clone_1.git

cd test_rebase_base.git
     # Add commit D and E to the base area

     echo "Commit D" > testfileD
     git add testfileD
     git commit -m "Commit D"

     echo "Commit E" > testfileE
     git add testfileE
     git commit -m "Commit E"

cd ..

cd test_rebase_clone_1.git
     # Add commit F and G to the clone_1 area

     echo "Commit F" > testfileF
     git add testfileF
     git commit -m "Commit F"

     echo "Commit G" > testfileG
     git add testfileG
     git commit -m "Commit G"

cd ..

     # clone from clone_1 into clone_2
     git clone test_rebase_clone_1.git test_rebase_clone_2.git

cd test_rebase_clone_2.git

     # change clone_2 to point to base

     git remote set-url origin "${WORKING_DIR:?}/test_rebase_base.git"

     # expecting this to pull in the "base" extra commits, and move the 
local HEAD commit after it in sequence
     git pull --rebase

cd ..

cd test_rebase_clone_1.git
     # do the same pull --rebase in clone_1
     git pull --rebase

cd ..

cd test_rebase_base.git
git log --oneline > "${WORKING_DIR:?}/test_rebase_base.oneline.log"
cd ..

cd test_rebase_clone_1.git
git log --oneline > "${WORKING_DIR:?}/test_rebase_clone_1.oneline.log"
cd ..

cd test_rebase_clone_2.git
git log --oneline > "${WORKING_DIR:?}/test_rebase_clone_2.oneline.log"
cd ..

# The test_rebase_clone_1.oneline.log and 
test_rebase_clone_2.oneline.log should match, but they don't

echo "done"

--------------------------------------------------------------------------------------------------

Re: Bug report for pull --rebase

[D. Ben Knoble]

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;
here's the log:

# bad: [683c54c999c301c2cd6f715c411407c413b1d84e] Git 2.49
# good: [e156455ea49124c140a67623f22a393db62d5d98] Git 2.0
git bisect start '--first-parent' '@' 'v2.0.0'
# bad: [4336fdb2efaf77b720f152c06b5ce2aa2e347fb6] Merge branch
'rs/nedalloc-fixlets'
git bisect bad 4336fdb2efaf77b720f152c06b5ce2aa2e347fb6
# bad: [130b664e442767587638b3e807a6f543168239d7] Merge branch
'js/travis-32bit-linux'
git bisect bad 130b664e442767587638b3e807a6f543168239d7
# bad: [922239e7da03f8e0a8c6ba809c1ee0cf3776f94a] Merge branch
'dk/p4-import-ctypes'
git bisect bad 922239e7da03f8e0a8c6ba809c1ee0cf3776f94a
# bad: [afa3ccbf44cb47cf988c6f40ce3ddb10829a9e7b] Merge branch
'jc/pretty-format-doc'
git bisect bad afa3ccbf44cb47cf988c6f40ce3ddb10829a9e7b
# bad: [7669461459aaee1587bac77c4a446e9365b582c7] Merge branch
'rs/merge-tree-simplify'
git bisect bad 7669461459aaee1587bac77c4a446e9365b582c7
# bad: [3d77f72efe79eb90f67aec9ecf6d4bd11fc9a78c] Merge branch
'jc/fix-clone-single-starting-at-a-tag'
git bisect bad 3d77f72efe79eb90f67aec9ecf6d4bd11fc9a78c
# bad: [5b3a58d459171f49ee8d486e4ac399eb2678605d] Merge branch
'jk/argv-array-for-child-process'
git bisect bad 5b3a58d459171f49ee8d486e4ac399eb2678605d
# bad: [d83c9c75e1edebd4ece3ad5223103f46fc38a4d3] Merge branch
'jk/grep-tell-run-command-to-cd-when-running-pager'
git bisect bad d83c9c75e1edebd4ece3ad5223103f46fc38a4d3
# bad: [e3798318b12502ae13a8e35e4a385665e810047f] Merge branch
'mm/mediawiki-encoding-fix'
git bisect bad e3798318b12502ae13a8e35e4a385665e810047f
# bad: [2e4b5dee97cb1524a88f0ee90450b139bfaff07b] Merge branch
'rs/ref-update-check-errors-early'
git bisect bad 2e4b5dee97cb1524a88f0ee90450b139bfaff07b
# bad: [f008cef4abb2a4db766b4a152b304aca91a0101a] Merge branch
'jc/apply-ignore-whitespace'
git bisect bad f008cef4abb2a4db766b4a152b304aca91a0101a
# bad: [bce14aa132e0064d9a9b1c7ad98e71e22c6e0272] Sync with 1.9.4
git bisect bad bce14aa132e0064d9a9b1c7ad98e71e22c6e0272
# bad: [d7172825321369cb951dd7bbfc0c12dc4ecbe518] t5537: re-drop http tests
git bisect bad d7172825321369cb951dd7bbfc0c12dc4ecbe518
# first bad commit: [d7172825321369cb951dd7bbfc0c12dc4ecbe518] t5537:
re-drop http tests

I think this just means the bug has been present since at least 2.0 (I
never checked if 2.0 was actually "good"; that was just as far back as
I was willing to go).

I didn't try to track down where it came from, though.

P.S. I was having trouble building master (something in the linker
with _false_but_the_compiler_does_not_know_it)? Revision 1ee85f0e21
(The twelfth batch, 2025-05-08). Log at
https://gist.github.com/benknoble/a8bdc272f44673e115f8b3e57d62e4f6.
P.P.S. I was flummoxed for a long time before I realized that "git
bisect run" sets GIT_DIR in the environment (checked by comparing the
script's environment in and out of "git bisect run"); is that
documented? Intended? Made it harder to drive Git in this script (see
"unset GIT_DIR").

-- 
D. Ben Knoble

Re: Bug report for pull --rebase

[Tuomas Ahola]

"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

Re: Bug report for pull --rebase

[Torsten Bögershausen]

On Fri, May 09, 2025 at 12:41:47PM -0400, D. Ben Knoble wrote:
> On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@gmail.com> wrote:
[]

> P.S. I was having trouble building master (something in the linker
> with _false_but_the_compiler_does_not_know_it)? Revision 1ee85f0e21
> (The twelfth batch, 2025-05-08). Log at

This has been fixed the last days.
The fix works under MacOs,
do you think that you can test the patch, please ?
<https://github.com/gitster/git/tree/tb/macos-false-but-the-compiler-does-not-know-it-fix>

Or look into the seen branch.

Re: Bug report for pull --rebase

[D. Ben Knoble]

(With apologies to duplicate recipients; missed "Reply All")

On Fri, May 9, 2025 at 1:59 PM Tuomas Ahola <taahol@utu.fi> wrote:
>
> "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

Re: Bug report for pull --rebase

[D. Ben Knoble]

On Sat, May 10, 2025 at 4:10 AM Torsten Bögershausen <tboegi@web.de> wrote:
>
> On Fri, May 09, 2025 at 12:41:47PM -0400, D. Ben Knoble wrote:
> > On Tue, May 6, 2025 at 5:44 PM Mr Bill <billc56196@gmail.com> wrote:
> []
>
> > P.S. I was having trouble building master (something in the linker
> > with _false_but_the_compiler_does_not_know_it)? Revision 1ee85f0e21
> > (The twelfth batch, 2025-05-08). Log at
>
> This has been fixed the last days.
> The fix works under MacOs,
> do you think that you can test the patch, please ?
> <https://github.com/gitster/git/tree/tb/macos-false-but-the-compiler-does-not-know-it-fix>
>
> Or look into the seen branch.

Indeed; a recent (unrelated) build off of the tip of master worked
just fine. Thanks!

-- 
D. Ben Knoble

Re: Bug report for pull --rebase

[Phillip Wood]

On 06/05/2025 22:36, Mr Bill 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.

After the url is updated the reflog for the upstream branch still has
an entry for "G". When "git pull --rebase" runs "git merge-base
--fork-point <upstream-branch> HEAD" it will return "G" and so that
commit will be excluded from the commits being rebased. Running

   git fetch && git rebase --no-fork-point

should keep the commits "F" and "G". Alternatively instead of updating
the url you could rename the "origin" remote and then add a new remote
called "origin" pointing to base. That way when you pull the reflog
for the upstream branch will not have entries from the previous
remote url.

> Then, in "clone_1" do "pull --rebase"; the F and G commits are retained.

That's because "F" and "G" are not in the reflog of the upstream branch
in clone_1.

It's debatable whether "git pull --rebase" should use "--fork-point" by
default. On the one hand it is convenient when the history of the
upstream branch has been rewritten but on the other hand it leads to
unexpected surprises like this. The fact that there isn't a way to
disable it and it ignores the rebase.forkPoint config setting does not
help.

Best Wishes

Phillip


> Something like this:
> 
> # commit trees:
> #
> #    base: A---B---C          (initial base repo with 3 commits)
> # clone_1: A---B---C          (clone_1 cloned from base at commit C)
> #    base: A---B---C---D---E  (base added extra commits D and E)
> # clone_1: A---B---C---F---G  (clone_1 added extra commits F and G)
> # clone_2: A---B---C---F---G  (clone_2 cloned from clone_1 at commit G)
> #
> # *** now, change clone_2 to use base as the upstream url, and fetch / pull / rebase to get up to date ***
> #
> # * set clone_2 upstream to point to base repo
> # * "pull --rebase" in clone_2 (should fetch from base repo and rebase F and G after D and E)
> #
> #   expected result: A---B---C---D---E---F---G
> #   actual result:   A---B---C---D---E
> #   commits F and G are gone
> #
> # Doing "pull --rebase" in clone_1 gives the expected result:
> #   expected result: A---B---C---D---E---F---G
> #
> 
> This looks like either stale state info after the "set-url" command,
> or I'm doing something wrong.
> 
> I can repeatedly cause this to happen in my local ffmpeg devel area, if that helps debug/test this.
> ... and answer questions, if any.
> 
> Thanks for the help!
> Bill
> 
> P.S. here's the test script I used for this:
> 
> --------------------------------------------------------------------------
> 
> #!/bin/bash
> 
> set -o errexit
> 
> BASE_WORKING_DIR="rebase_bug.working"
> 
> # Clean up the test area
> rm -rf "${BASE_WORKING_DIR:?}"
> mkdir  "${BASE_WORKING_DIR:?}"
> cd     "${BASE_WORKING_DIR:?}"
> 
> WORKING_DIR="${PWD}"
> 
> mkdir test_rebase_base.git
> cd test_rebase_base.git
> 
>      # create the base git repo, with commit A, B and C
>      git init
>      echo "Commit A" > testfileA
>      git add testfileA
>      git commit -m "Commit A"
> 
>      echo "Commit B" > testfileB
>      git add testfileB
>      git commit -m "Commit B"
> 
>      echo "Commit C" > testfileC
>      git add testfileC
>      git commit -m "Commit C"
> 
> cd ..
> 
>      # Clone the base area into the clone_1 area
>      git clone test_rebase_base.git test_rebase_clone_1.git
> 
> cd test_rebase_base.git
>      # Add commit D and E to the base area
> 
>      echo "Commit D" > testfileD
>      git add testfileD
>      git commit -m "Commit D"
> 
>      echo "Commit E" > testfileE
>      git add testfileE
>      git commit -m "Commit E"
> 
> cd ..
> 
> cd test_rebase_clone_1.git
>      # Add commit F and G to the clone_1 area
> 
>      echo "Commit F" > testfileF
>      git add testfileF
>      git commit -m "Commit F"
> 
>      echo "Commit G" > testfileG
>      git add testfileG
>      git commit -m "Commit G"
> 
> cd ..
> 
>      # clone from clone_1 into clone_2
>      git clone test_rebase_clone_1.git test_rebase_clone_2.git
> 
> cd test_rebase_clone_2.git
> 
>      # change clone_2 to point to base
> 
>      git remote set-url origin "${WORKING_DIR:?}/test_rebase_base.git"
> 
>      # expecting this to pull in the "base" extra commits, and move the local HEAD commit after it in sequence
>      git pull --rebase
> 
> cd ..
> 
> cd test_rebase_clone_1.git
>      # do the same pull --rebase in clone_1
>      git pull --rebase
> 
> cd ..
> 
> cd test_rebase_base.git
> git log --oneline > "${WORKING_DIR:?}/test_rebase_base.oneline.log"
> cd ..
> 
> cd test_rebase_clone_1.git
> git log --oneline > "${WORKING_DIR:?}/test_rebase_clone_1.oneline.log"
> cd ..
> 
> cd test_rebase_clone_2.git
> git log --oneline > "${WORKING_DIR:?}/test_rebase_clone_2.oneline.log"
> cd ..
> 
> # The test_rebase_clone_1.oneline.log and test_rebase_clone_2.oneline.log should match, but they don't
> 
> echo "done"
> 
> --------------------------------------------------------------------------------------------------
> 

Re: Bug report for pull --rebase

[Mr Bill]

On 05/12/2025 09:07 AM, Phillip Wood wrote:
> On 06/05/2025 22:36, Mr Bill 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.
>
> After the url is updated the reflog for the upstream branch still has
> an entry for "G". When "git pull --rebase" runs "git merge-base
> --fork-point <upstream-branch> HEAD" it will return "G" and so that
> commit will be excluded from the commits being rebased.

Thank you for your comments on this (Ben and Tuomas, also)

I've seen this situation when looking at this issue.

Running "git merge-base --fork-point..." returns different values for
the clone_1 and clone_2 branches:
* clone_1 points to commit "C"
* clone_2 points to commit "G"

... apparently because of the extra "G" entry for the upstream branch.

I was expecting running "git fetch" after the "git remote set-url..." would
update the upstream HEAD information to reflect the new upstream repo state.
(and "git fetch" happens as part of "git pull --rebase", so that's 
covered, too)

In my case, I can use the "rebase --no-fork-point" style to keep my updates.

Thanks again!
- Bill

> Running
>
>   git fetch && git rebase --no-fork-point
>
> should keep the commits "F" and "G". Alternatively instead of updating
> the url you could rename the "origin" remote and then add a new remote
> called "origin" pointing to base. That way when you pull the reflog
> for the upstream branch will not have entries from the previous
> remote url.
>
>> Then, in "clone_1" do "pull --rebase"; the F and G commits are retained.
>
> That's because "F" and "G" are not in the reflog of the upstream branch
> in clone_1.
>
> It's debatable whether "git pull --rebase" should use "--fork-point" by
> default. On the one hand it is convenient when the history of the
> upstream branch has been rewritten but on the other hand it leads to
> unexpected surprises like this. The fact that there isn't a way to
> disable it and it ignores the rebase.forkPoint config setting does not
> help.
>
> Best Wishes
>
> Phillip
>
>
>> Something like this:
>>
>> # commit trees:
>> #
>> #    base: A---B---C          (initial base repo with 3 commits)
>> # clone_1: A---B---C          (clone_1 cloned from base at commit C)
>> #    base: A---B---C---D---E  (base added extra commits D and E)
>> # clone_1: A---B---C---F---G  (clone_1 added extra commits F and G)
>> # clone_2: A---B---C---F---G  (clone_2 cloned from clone_1 at commit G)
>> #
>> # *** now, change clone_2 to use base as the upstream url, and fetch 
>> / pull / rebase to get up to date ***
>> #
>> # * set clone_2 upstream to point to base repo
>> # * "pull --rebase" in clone_2 (should fetch from base repo and 
>> rebase F and G after D and E)
>> #
>> #   expected result: A---B---C---D---E---F---G
>> #   actual result:   A---B---C---D---E
>> #   commits F and G are gone
>> #
>> # Doing "pull --rebase" in clone_1 gives the expected result:
>> #   expected result: A---B---C---D---E---F---G
>> #
>>
>> This looks like either stale state info after the "set-url" command,
>> or I'm doing something wrong.
>>
>> I can repeatedly cause this to happen in my local ffmpeg devel area, 
>> if that helps debug/test this.
>> ... and answer questions, if any.
>>
>> Thanks for the help!
>> Bill
>>
>> P.S. here's the test script I used for this:
>>
>> -------------------------------------------------------------------------- 
>>
>>
>> #!/bin/bash
>>
>> set -o errexit
>>
>> BASE_WORKING_DIR="rebase_bug.working"
>>
>> # Clean up the test area
>> rm -rf "${BASE_WORKING_DIR:?}"
>> mkdir  "${BASE_WORKING_DIR:?}"
>> cd     "${BASE_WORKING_DIR:?}"
>>
>> WORKING_DIR="${PWD}"
>>
>> mkdir test_rebase_base.git
>> cd test_rebase_base.git
>>
>>      # create the base git repo, with commit A, B and C
>>      git init
>>      echo "Commit A" > testfileA
>>      git add testfileA
>>      git commit -m "Commit A"
>>
>>      echo "Commit B" > testfileB
>>      git add testfileB
>>      git commit -m "Commit B"
>>
>>      echo "Commit C" > testfileC
>>      git add testfileC
>>      git commit -m "Commit C"
>>
>> cd ..
>>
>>      # Clone the base area into the clone_1 area
>>      git clone test_rebase_base.git test_rebase_clone_1.git
>>
>> cd test_rebase_base.git
>>      # Add commit D and E to the base area
>>
>>      echo "Commit D" > testfileD
>>      git add testfileD
>>      git commit -m "Commit D"
>>
>>      echo "Commit E" > testfileE
>>      git add testfileE
>>      git commit -m "Commit E"
>>
>> cd ..
>>
>> cd test_rebase_clone_1.git
>>      # Add commit F and G to the clone_1 area
>>
>>      echo "Commit F" > testfileF
>>      git add testfileF
>>      git commit -m "Commit F"
>>
>>      echo "Commit G" > testfileG
>>      git add testfileG
>>      git commit -m "Commit G"
>>
>> cd ..
>>
>>      # clone from clone_1 into clone_2
>>      git clone test_rebase_clone_1.git test_rebase_clone_2.git
>>
>> cd test_rebase_clone_2.git
>>
>>      # change clone_2 to point to base
>>
>>      git remote set-url origin "${WORKING_DIR:?}/test_rebase_base.git"
>>
>>      # expecting this to pull in the "base" extra commits, and move 
>> the local HEAD commit after it in sequence
>>      git pull --rebase
>>
>> cd ..
>>
>> cd test_rebase_clone_1.git
>>      # do the same pull --rebase in clone_1
>>      git pull --rebase
>>
>> cd ..
>>
>> cd test_rebase_base.git
>> git log --oneline > "${WORKING_DIR:?}/test_rebase_base.oneline.log"
>> cd ..
>>
>> cd test_rebase_clone_1.git
>> git log --oneline > "${WORKING_DIR:?}/test_rebase_clone_1.oneline.log"
>> cd ..
>>
>> cd test_rebase_clone_2.git
>> git log --oneline > "${WORKING_DIR:?}/test_rebase_clone_2.oneline.log"
>> cd ..
>>
>> # The test_rebase_clone_1.oneline.log and 
>> test_rebase_clone_2.oneline.log should match, but they don't
>>
>> echo "done"
>>
>> -------------------------------------------------------------------------------------------------- 
>>
>>
>