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