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

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

Hi Philip,
oh, so I guessed correctly...
Could you be more specific about the copy/rename issue of the apply backend ?
Is there any bug report I can refer to ?

Thank you very much for your support

Marco

On Thu, Jun 24, 2021 at 8:39 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>
> 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
> >>>
> >>