Re: Nonexistent changes appear rebasing but only with rebase.backend=apply

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Marco

On 18/06/2021 16:21, Marco Giuliano wrote:
> Hi All
> 
> I'm facing a strange anomaly during rebase.
> I'll try to explain what happens because unfortunately I cannot share
> more information since it's confidential and unfortunately an
> anonymized export does not reproduce the issue.
> 
> I have the following repository status:
> 
>     * commit 2 (BRANCH X)
>     |
>     |  * commit 4 (BRANCH Y) (HEAD)
>     |  |
>     |  * commit 3
>     | /
>     |/
>     * commit 1
>     |
>     |
>   (...)
> 
> What I'm trying to do is rebasing branch Y on branch X, with the command:
> git rebase X
> 
> The anomaly is that, among other expected conflicts, also two files
> (fileA, fileB) appear modified in both branches, but those two files
> have not been modified in any of the 4 commits you see in the graph
> above!
> The anomaly appears only with the config setting rebase.backend=apply,
> while not with rebase.backend=merge (*).
> 
> This might not be caused by rebase command itself, but rather by some
> previous operations which might have accidentally "broken" something
> and that the rebase simply makes them appear.
> You need to know that commit 4 is the result of several squash and
> reordering of multiple commits; is it possible that some of those
> operations have created some "leftovers" ?
> 
> I know this is difficult without seeing the actual repository, but
> could you just give me some advice or point me to the place where I
> can investigate ?

That certainly sounds quite strange. I think the patches used by the 
apply backend are stored in .git/rebased-patches, it might be worth 
looking at that file when the rebase stops for you to resolve the 
conflict resolution to see if that sheds any light on which commits the 
conflicts are coming from. Failing that does the content of the 
conflicts provide any clues as to which commits they are coming from? 
You could also try matching the blob id's from the index line of `diff 
--cc` to the index lines in `git log -p` to try and find where they are 
coming from.

Rebase ought to just replay the commits so in theory it shouldn't matter 
that you've been squashing and rearranging commits. What does `git log 
-p branch-x...branch-y fileA fileB` show? (it shouldn't show anything if 
those files are not touched by any of the commits)

Best Wishes

Phillip

> (*)
> When the anomaly first appeared, I was using git for windows, version
> < 2.26.0 (unfortunately I cannot recover the exact number); I decided
> to upgrade git to 2.31.1 and the anomaly disappeared. Investigating
> the release notes, I noticed that rebase.backend default value changed
> from apply to rebase from version 2.26.0.
> I also copied the repository on linux (with git 2.31.0), and the
> behavior is the same.
> 
> Thanks in advance for any help,
> Best Regards,
> Marco
>