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

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

Hi Marco

On 24/06/2021 17:23, Marco Giuliano wrote:
> Thanks Felipe and Philip for your answers.
> 
> Let's proceed in order:
> @Felipe: I tried rebasing with --no-fork-point but the problem remains the same
> 
> @Philip:
> I'm a basic git user, so bear with me if I say silly things...
> I tried to search for rebased-patches in .git folder when rebase
> stopped waiting for
> conflict resolution, but I didn't find any file named like that.
> There's a folder named rebase-apply though did you mean that ?

Looking at the source I thought they ended up just in .git but I haven't 
checked again, as you seem to have found the source of the problem below 
lets not worry about that.

> Anyway, looking at the conflict file of "fileA" directly (not behind a
> visual diff tool) I noticed that the marker line >>>>>>>> COMMIT
> DESCR: FILENAME indicates a different file name then the current
> conflicted file.
> That reminded me that those two files A & B, were actually copies
> (real copy, not symlink) of other two files inside the same repo.
> Is it somehow possible that auto-detected-renaming is involved in this
> (since the files are identical but in two different locations) ?
> Trying to give you some hints, maybe it is totally unrelated...

I meant to ask if anything had been copied or renamed but forgot. The 
merge backend detects copies and renames and handles them correctly but 
the apply backend does not so I think this is the source of the discrepancy.

Best Wishes

Phillip

> About the blob check you suggested, please be patient but I didn't
> understand exactly how to proceed.
> 
> Thanks again for your support,
> Marco
> 
> 
> 
> On Sun, Jun 20, 2021 at 8:02 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>
>> 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
>>>
>>