Re: Bug report for pull --rebase

["D. Ben Knoble" <ben.knoble@gmail.com>]

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