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

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 [off-list ref] wrote:

quoted

Hi Marco

On 18/06/2021 16:21, Marco Giuliano wrote:

quoted

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

quoted

(*)
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