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