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

[Marco Giuliano <marco.giuliano@tesisquare.com>]

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 ?

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...

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
> >
>