{"thread":{"id":"55959","subject":"Nonexistent changes appear rebasing but only with rebase.backend=apply","startedAt":"2021-06-18T15:28:09Z","lastAt":"2021-06-29T18:58:52Z","messageCount":9,"participants":["Marco Giuliano","Felipe Contreras","Phillip Wood","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"427835","messageId":"CANLwWg4hG=iv9qjOmGHSJ7z7Y+vvvP+x0o3DfR5bH5A-C6_7aQ@mail.gmail.com","threadId":"55959","inReplyTo":null,"subject":"Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Marco Giuliano","fromEmail":"marco.giuliano@tesisquare.com","sentAt":"2021-06-18T15:21:23Z","receivedAt":"2021-06-18T15:28:09Z","isPatch":false,"sender":{"key":"marco.giuliano@tesisquare.com","avatar":null},"body":"Hi All\n\nI'm facing a strange anomaly during rebase.\nI'll try to explain what happens because unfortunately I cannot share\nmore information since it's confidential and unfortunately an\nanonymized export does not reproduce the issue.\n\nI have the following repository status:\n\n   * commit 2 (BRANCH X)\n   |\n   |  * commit 4 (BRANCH Y) (HEAD)\n   |  |\n   |  * commit 3\n   | /\n   |/\n   * commit 1\n   |\n   |\n (...)\n\nWhat I'm trying to do is rebasing branch Y on branch X, with the command:\ngit rebase X\n\nThe anomaly is that, among other expected conflicts, also two files\n(fileA, fileB) appear modified in both branches, but those two files\nhave not been modified in any of the 4 commits you see in the graph\nabove!\nThe anomaly appears only with the config setting rebase.backend=apply,\nwhile not with rebase.backend=merge (*).\n\nThis might not be caused by rebase command itself, but rather by some\nprevious operations which might have accidentally \"broken\" something\nand that the rebase simply makes them appear.\nYou need to know that commit 4 is the result of several squash and\nreordering of multiple commits; is it possible that some of those\noperations have created some \"leftovers\" ?\n\nI know this is difficult without seeing the actual repository, but\ncould you just give me some advice or point me to the place where I\ncan investigate ?\n\n(*)\nWhen the anomaly first appeared, I was using git for windows, version\n< 2.26.0 (unfortunately I cannot recover the exact number); I decided\nto upgrade git to 2.31.1 and the anomaly disappeared. Investigating\nthe release notes, I noticed that rebase.backend default value changed\nfrom apply to rebase from version 2.26.0.\nI also copied the repository on linux (with git 2.31.0), and the\nbehavior is the same.\n\nThanks in advance for any help,\nBest Regards,\nMarco\n"},{"id":"427923","messageId":"60cd2fded6889_ca711208d7@natae.notmuch","threadId":"55959","inReplyTo":"CANLwWg4hG=iv9qjOmGHSJ7z7Y+vvvP+x0o3DfR5bH5A-C6_7aQ@mail.gmail.com","subject":"RE: Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-18T23:44:30Z","receivedAt":"2021-06-18T23:44:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Marco Giuliano wrote:\n> This might not be caused by rebase command itself, but rather by some\n> previous operations which might have accidentally \"broken\" something\n> and that the rebase simply makes them appear.\n> You need to know that commit 4 is the result of several squash and\n> reordering of multiple commits; is it possible that some of those\n> operations have created some \"leftovers\" ?\n\nSmells like the reflog.\n\nHave you tried --no-fork-point?\n\n-- \nFelipe Contreras\n"},{"id":"427990","messageId":"9a83ef22-2291-1364-b0a8-1eb8257972a2@gmail.com","threadId":"55959","inReplyTo":"CANLwWg4hG=iv9qjOmGHSJ7z7Y+vvvP+x0o3DfR5bH5A-C6_7aQ@mail.gmail.com","subject":"Re: Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2021-06-20T18:02:18Z","receivedAt":"2021-06-20T18:02:22Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Marco\n\nOn 18/06/2021 16:21, Marco Giuliano wrote:\n> Hi All\n> \n> I'm facing a strange anomaly during rebase.\n> I'll try to explain what happens because unfortunately I cannot share\n> more information since it's confidential and unfortunately an\n> anonymized export does not reproduce the issue.\n> \n> I have the following repository status:\n> \n>     * commit 2 (BRANCH X)\n>     |\n>     |  * commit 4 (BRANCH Y) (HEAD)\n>     |  |\n>     |  * commit 3\n>     | /\n>     |/\n>     * commit 1\n>     |\n>     |\n>   (...)\n> \n> What I'm trying to do is rebasing branch Y on branch X, with the command:\n> git rebase X\n> \n> The anomaly is that, among other expected conflicts, also two files\n> (fileA, fileB) appear modified in both branches, but those two files\n> have not been modified in any of the 4 commits you see in the graph\n> above!\n> The anomaly appears only with the config setting rebase.backend=apply,\n> while not with rebase.backend=merge (*).\n> \n> This might not be caused by rebase command itself, but rather by some\n> previous operations which might have accidentally \"broken\" something\n> and that the rebase simply makes them appear.\n> You need to know that commit 4 is the result of several squash and\n> reordering of multiple commits; is it possible that some of those\n> operations have created some \"leftovers\" ?\n> \n> I know this is difficult without seeing the actual repository, but\n> could you just give me some advice or point me to the place where I\n> can investigate ?\n\nThat certainly sounds quite strange. I think the patches used by the \napply backend are stored in .git/rebased-patches, it might be worth \nlooking at that file when the rebase stops for you to resolve the \nconflict resolution to see if that sheds any light on which commits the \nconflicts are coming from. Failing that does the content of the \nconflicts provide any clues as to which commits they are coming from? \nYou could also try matching the blob id's from the index line of `diff \n--cc` to the index lines in `git log -p` to try and find where they are \ncoming from.\n\nRebase ought to just replay the commits so in theory it shouldn't matter \nthat you've been squashing and rearranging commits. What does `git log \n-p branch-x...branch-y fileA fileB` show? (it shouldn't show anything if \nthose files are not touched by any of the commits)\n\nBest Wishes\n\nPhillip\n\n> (*)\n> When the anomaly first appeared, I was using git for windows, version\n> < 2.26.0 (unfortunately I cannot recover the exact number); I decided\n> to upgrade git to 2.31.1 and the anomaly disappeared. Investigating\n> the release notes, I noticed that rebase.backend default value changed\n> from apply to rebase from version 2.26.0.\n> I also copied the repository on linux (with git 2.31.0), and the\n> behavior is the same.\n> \n> Thanks in advance for any help,\n> Best Regards,\n> Marco\n> \n\n"},{"id":"428385","messageId":"CANLwWg5Lcf7PYtZ49U-KZ_3UYVb9FJ-g1B+eFYoO2D1t5UArmw@mail.gmail.com","threadId":"55959","inReplyTo":"9a83ef22-2291-1364-b0a8-1eb8257972a2@gmail.com","subject":"Re: Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Marco Giuliano","fromEmail":"marco.giuliano@tesisquare.com","sentAt":"2021-06-24T16:23:57Z","receivedAt":"2021-06-24T16:24:25Z","isPatch":false,"sender":{"key":"marco.giuliano@tesisquare.com","avatar":null},"body":"Thanks Felipe and Philip for your answers.\n\nLet's proceed in order:\n@Felipe: I tried rebasing with --no-fork-point but the problem remains the same\n\n@Philip:\nI'm a basic git user, so bear with me if I say silly things...\nI tried to search for rebased-patches in .git folder when rebase\nstopped waiting for\nconflict resolution, but I didn't find any file named like that.\nThere's a folder named rebase-apply though did you mean that ?\n\nAnyway, looking at the conflict file of \"fileA\" directly (not behind a\nvisual diff tool) I noticed that the marker line >>>>>>>> COMMIT\nDESCR: FILENAME indicates a different file name then the current\nconflicted file.\nThat reminded me that those two files A & B, were actually copies\n(real copy, not symlink) of other two files inside the same repo.\nIs it somehow possible that auto-detected-renaming is involved in this\n(since the files are identical but in two different locations) ?\nTrying to give you some hints, maybe it is totally unrelated...\n\nAbout the blob check you suggested, please be patient but I didn't\nunderstand exactly how to proceed.\n\nThanks again for your support,\nMarco\n\n\n\nOn Sun, Jun 20, 2021 at 8:02 PM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>\n> Hi Marco\n>\n> On 18/06/2021 16:21, Marco Giuliano wrote:\n> > Hi All\n> >\n> > I'm facing a strange anomaly during rebase.\n> > I'll try to explain what happens because unfortunately I cannot share\n> > more information since it's confidential and unfortunately an\n> > anonymized export does not reproduce the issue.\n> >\n> > I have the following repository status:\n> >\n> >     * commit 2 (BRANCH X)\n> >     |\n> >     |  * commit 4 (BRANCH Y) (HEAD)\n> >     |  |\n> >     |  * commit 3\n> >     | /\n> >     |/\n> >     * commit 1\n> >     |\n> >     |\n> >   (...)\n> >\n> > What I'm trying to do is rebasing branch Y on branch X, with the command:\n> > git rebase X\n> >\n> > The anomaly is that, among other expected conflicts, also two files\n> > (fileA, fileB) appear modified in both branches, but those two files\n> > have not been modified in any of the 4 commits you see in the graph\n> > above!\n> > The anomaly appears only with the config setting rebase.backend=apply,\n> > while not with rebase.backend=merge (*).\n> >\n> > This might not be caused by rebase command itself, but rather by some\n> > previous operations which might have accidentally \"broken\" something\n> > and that the rebase simply makes them appear.\n> > You need to know that commit 4 is the result of several squash and\n> > reordering of multiple commits; is it possible that some of those\n> > operations have created some \"leftovers\" ?\n> >\n> > I know this is difficult without seeing the actual repository, but\n> > could you just give me some advice or point me to the place where I\n> > can investigate ?\n>\n> That certainly sounds quite strange. I think the patches used by the\n> apply backend are stored in .git/rebased-patches, it might be worth\n> looking at that file when the rebase stops for you to resolve the\n> conflict resolution to see if that sheds any light on which commits the\n> conflicts are coming from. Failing that does the content of the\n> conflicts provide any clues as to which commits they are coming from?\n> You could also try matching the blob id's from the index line of `diff\n> --cc` to the index lines in `git log -p` to try and find where they are\n> coming from.\n>\n> Rebase ought to just replay the commits so in theory it shouldn't matter\n> that you've been squashing and rearranging commits. What does `git log\n> -p branch-x...branch-y fileA fileB` show? (it shouldn't show anything if\n> those files are not touched by any of the commits)\n>\n> Best Wishes\n>\n> Phillip\n>\n> > (*)\n> > When the anomaly first appeared, I was using git for windows, version\n> > < 2.26.0 (unfortunately I cannot recover the exact number); I decided\n> > to upgrade git to 2.31.1 and the anomaly disappeared. Investigating\n> > the release notes, I noticed that rebase.backend default value changed\n> > from apply to rebase from version 2.26.0.\n> > I also copied the repository on linux (with git 2.31.0), and the\n> > behavior is the same.\n> >\n> > Thanks in advance for any help,\n> > Best Regards,\n> > Marco\n> >\n>\n"},{"id":"428395","messageId":"6b604658-8f7e-ae5d-7161-c48aed7ccbd0@gmail.com","threadId":"55959","inReplyTo":"CANLwWg5Lcf7PYtZ49U-KZ_3UYVb9FJ-g1B+eFYoO2D1t5UArmw@mail.gmail.com","subject":"Re: Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2021-06-24T18:39:11Z","receivedAt":"2021-06-24T18:39:32Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Marco\n\nOn 24/06/2021 17:23, Marco Giuliano wrote:\n> Thanks Felipe and Philip for your answers.\n> \n> Let's proceed in order:\n> @Felipe: I tried rebasing with --no-fork-point but the problem remains the same\n> \n> @Philip:\n> I'm a basic git user, so bear with me if I say silly things...\n> I tried to search for rebased-patches in .git folder when rebase\n> stopped waiting for\n> conflict resolution, but I didn't find any file named like that.\n> There's a folder named rebase-apply though did you mean that ?\n\nLooking at the source I thought they ended up just in .git but I haven't \nchecked again, as you seem to have found the source of the problem below \nlets not worry about that.\n\n> Anyway, looking at the conflict file of \"fileA\" directly (not behind a\n> visual diff tool) I noticed that the marker line >>>>>>>> COMMIT\n> DESCR: FILENAME indicates a different file name then the current\n> conflicted file.\n> That reminded me that those two files A & B, were actually copies\n> (real copy, not symlink) of other two files inside the same repo.\n> Is it somehow possible that auto-detected-renaming is involved in this\n> (since the files are identical but in two different locations) ?\n> Trying to give you some hints, maybe it is totally unrelated...\n\nI meant to ask if anything had been copied or renamed but forgot. The \nmerge backend detects copies and renames and handles them correctly but \nthe apply backend does not so I think this is the source of the discrepancy.\n\nBest Wishes\n\nPhillip\n\n> About the blob check you suggested, please be patient but I didn't\n> understand exactly how to proceed.\n> \n> Thanks again for your support,\n> Marco\n> \n> \n> \n> On Sun, Jun 20, 2021 at 8:02 PM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>>\n>> Hi Marco\n>>\n>> On 18/06/2021 16:21, Marco Giuliano wrote:\n>>> Hi All\n>>>\n>>> I'm facing a strange anomaly during rebase.\n>>> I'll try to explain what happens because unfortunately I cannot share\n>>> more information since it's confidential and unfortunately an\n>>> anonymized export does not reproduce the issue.\n>>>\n>>> I have the following repository status:\n>>>\n>>>      * commit 2 (BRANCH X)\n>>>      |\n>>>      |  * commit 4 (BRANCH Y) (HEAD)\n>>>      |  |\n>>>      |  * commit 3\n>>>      | /\n>>>      |/\n>>>      * commit 1\n>>>      |\n>>>      |\n>>>    (...)\n>>>\n>>> What I'm trying to do is rebasing branch Y on branch X, with the command:\n>>> git rebase X\n>>>\n>>> The anomaly is that, among other expected conflicts, also two files\n>>> (fileA, fileB) appear modified in both branches, but those two files\n>>> have not been modified in any of the 4 commits you see in the graph\n>>> above!\n>>> The anomaly appears only with the config setting rebase.backend=apply,\n>>> while not with rebase.backend=merge (*).\n>>>\n>>> This might not be caused by rebase command itself, but rather by some\n>>> previous operations which might have accidentally \"broken\" something\n>>> and that the rebase simply makes them appear.\n>>> You need to know that commit 4 is the result of several squash and\n>>> reordering of multiple commits; is it possible that some of those\n>>> operations have created some \"leftovers\" ?\n>>>\n>>> I know this is difficult without seeing the actual repository, but\n>>> could you just give me some advice or point me to the place where I\n>>> can investigate ?\n>>\n>> That certainly sounds quite strange. I think the patches used by the\n>> apply backend are stored in .git/rebased-patches, it might be worth\n>> looking at that file when the rebase stops for you to resolve the\n>> conflict resolution to see if that sheds any light on which commits the\n>> conflicts are coming from. Failing that does the content of the\n>> conflicts provide any clues as to which commits they are coming from?\n>> You could also try matching the blob id's from the index line of `diff\n>> --cc` to the index lines in `git log -p` to try and find where they are\n>> coming from.\n>>\n>> Rebase ought to just replay the commits so in theory it shouldn't matter\n>> that you've been squashing and rearranging commits. What does `git log\n>> -p branch-x...branch-y fileA fileB` show? (it shouldn't show anything if\n>> those files are not touched by any of the commits)\n>>\n>> Best Wishes\n>>\n>> Phillip\n>>\n>>> (*)\n>>> When the anomaly first appeared, I was using git for windows, version\n>>> < 2.26.0 (unfortunately I cannot recover the exact number); I decided\n>>> to upgrade git to 2.31.1 and the anomaly disappeared. Investigating\n>>> the release notes, I noticed that rebase.backend default value changed\n>>> from apply to rebase from version 2.26.0.\n>>> I also copied the repository on linux (with git 2.31.0), and the\n>>> behavior is the same.\n>>>\n>>> Thanks in advance for any help,\n>>> Best Regards,\n>>> Marco\n>>>\n>>\n"},{"id":"428455","messageId":"CANLwWg7YFC2VrRYz1PR1U9SVG5yiyRVnyMspGc8PqKktouz8dQ@mail.gmail.com","threadId":"55959","inReplyTo":"6b604658-8f7e-ae5d-7161-c48aed7ccbd0@gmail.com","subject":"Re: Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Marco Giuliano","fromEmail":"marco.giuliano@tesisquare.com","sentAt":"2021-06-25T07:12:24Z","receivedAt":"2021-06-25T07:12:53Z","isPatch":false,"sender":{"key":"marco.giuliano@tesisquare.com","avatar":null},"body":"Hi Philip,\noh, so I guessed correctly...\nCould you be more specific about the copy/rename issue of the apply backend ?\nIs there any bug report I can refer to ?\n\nThank you very much for your support\n\nMarco\n\nOn Thu, Jun 24, 2021 at 8:39 PM Phillip Wood <phillip.wood123@gmail.com> wrote:\n>\n> Hi Marco\n>\n> On 24/06/2021 17:23, Marco Giuliano wrote:\n> > Thanks Felipe and Philip for your answers.\n> >\n> > Let's proceed in order:\n> > @Felipe: I tried rebasing with --no-fork-point but the problem remains the same\n> >\n> > @Philip:\n> > I'm a basic git user, so bear with me if I say silly things...\n> > I tried to search for rebased-patches in .git folder when rebase\n> > stopped waiting for\n> > conflict resolution, but I didn't find any file named like that.\n> > There's a folder named rebase-apply though did you mean that ?\n>\n> Looking at the source I thought they ended up just in .git but I haven't\n> checked again, as you seem to have found the source of the problem below\n> lets not worry about that.\n>\n> > Anyway, looking at the conflict file of \"fileA\" directly (not behind a\n> > visual diff tool) I noticed that the marker line >>>>>>>> COMMIT\n> > DESCR: FILENAME indicates a different file name then the current\n> > conflicted file.\n> > That reminded me that those two files A & B, were actually copies\n> > (real copy, not symlink) of other two files inside the same repo.\n> > Is it somehow possible that auto-detected-renaming is involved in this\n> > (since the files are identical but in two different locations) ?\n> > Trying to give you some hints, maybe it is totally unrelated...\n>\n> I meant to ask if anything had been copied or renamed but forgot. The\n> merge backend detects copies and renames and handles them correctly but\n> the apply backend does not so I think this is the source of the discrepancy.\n>\n> Best Wishes\n>\n> Phillip\n>\n> > About the blob check you suggested, please be patient but I didn't\n> > understand exactly how to proceed.\n> >\n> > Thanks again for your support,\n> > Marco\n> >\n> >\n> >\n> > On Sun, Jun 20, 2021 at 8:02 PM Phillip Wood <phillip.wood123@gmail.com> wrote:\n> >>\n> >> Hi Marco\n> >>\n> >> On 18/06/2021 16:21, Marco Giuliano wrote:\n> >>> Hi All\n> >>>\n> >>> I'm facing a strange anomaly during rebase.\n> >>> I'll try to explain what happens because unfortunately I cannot share\n> >>> more information since it's confidential and unfortunately an\n> >>> anonymized export does not reproduce the issue.\n> >>>\n> >>> I have the following repository status:\n> >>>\n> >>>      * commit 2 (BRANCH X)\n> >>>      |\n> >>>      |  * commit 4 (BRANCH Y) (HEAD)\n> >>>      |  |\n> >>>      |  * commit 3\n> >>>      | /\n> >>>      |/\n> >>>      * commit 1\n> >>>      |\n> >>>      |\n> >>>    (...)\n> >>>\n> >>> What I'm trying to do is rebasing branch Y on branch X, with the command:\n> >>> git rebase X\n> >>>\n> >>> The anomaly is that, among other expected conflicts, also two files\n> >>> (fileA, fileB) appear modified in both branches, but those two files\n> >>> have not been modified in any of the 4 commits you see in the graph\n> >>> above!\n> >>> The anomaly appears only with the config setting rebase.backend=apply,\n> >>> while not with rebase.backend=merge (*).\n> >>>\n> >>> This might not be caused by rebase command itself, but rather by some\n> >>> previous operations which might have accidentally \"broken\" something\n> >>> and that the rebase simply makes them appear.\n> >>> You need to know that commit 4 is the result of several squash and\n> >>> reordering of multiple commits; is it possible that some of those\n> >>> operations have created some \"leftovers\" ?\n> >>>\n> >>> I know this is difficult without seeing the actual repository, but\n> >>> could you just give me some advice or point me to the place where I\n> >>> can investigate ?\n> >>\n> >> That certainly sounds quite strange. I think the patches used by the\n> >> apply backend are stored in .git/rebased-patches, it might be worth\n> >> looking at that file when the rebase stops for you to resolve the\n> >> conflict resolution to see if that sheds any light on which commits the\n> >> conflicts are coming from. Failing that does the content of the\n> >> conflicts provide any clues as to which commits they are coming from?\n> >> You could also try matching the blob id's from the index line of `diff\n> >> --cc` to the index lines in `git log -p` to try and find where they are\n> >> coming from.\n> >>\n> >> Rebase ought to just replay the commits so in theory it shouldn't matter\n> >> that you've been squashing and rearranging commits. What does `git log\n> >> -p branch-x...branch-y fileA fileB` show? (it shouldn't show anything if\n> >> those files are not touched by any of the commits)\n> >>\n> >> Best Wishes\n> >>\n> >> Phillip\n> >>\n> >>> (*)\n> >>> When the anomaly first appeared, I was using git for windows, version\n> >>> < 2.26.0 (unfortunately I cannot recover the exact number); I decided\n> >>> to upgrade git to 2.31.1 and the anomaly disappeared. Investigating\n> >>> the release notes, I noticed that rebase.backend default value changed\n> >>> from apply to rebase from version 2.26.0.\n> >>> I also copied the repository on linux (with git 2.31.0), and the\n> >>> behavior is the same.\n> >>>\n> >>> Thanks in advance for any help,\n> >>> Best Regards,\n> >>> Marco\n> >>>\n> >>\n"},{"id":"428485","messageId":"60d5ff68194a1_c23720822@natae.notmuch","threadId":"55959","inReplyTo":"CANLwWg4hG=iv9qjOmGHSJ7z7Y+vvvP+x0o3DfR5bH5A-C6_7aQ@mail.gmail.com","subject":"RE: Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-06-25T16:08:08Z","receivedAt":"2021-06-25T16:08:12Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Marco Giuliano wrote:\n\n> I have the following repository status:\n> \n>    * commit 2 (BRANCH X)\n>    |\n>    |  * commit 4 (BRANCH Y) (HEAD)\n>    |  |\n>    |  * commit 3\n>    | /\n>    |/\n>    * commit 1\n>    |\n>    |\n>  (...)\n> \n> What I'm trying to do is rebasing branch Y on branch X, with the command:\n> git rebase X\n\nHave you tried using --onto?\n\n  git rebase --onto X commt1\n\n-- \nFelipe Contreras\n"},{"id":"428513","messageId":"CABPp-BH1COE8worEAuu3M_LNJfVhW3Y6+1r8zfUcVaTrVgjG5w@mail.gmail.com","threadId":"55959","inReplyTo":"CANLwWg7YFC2VrRYz1PR1U9SVG5yiyRVnyMspGc8PqKktouz8dQ@mail.gmail.com","subject":"Re: Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-26T07:53:23Z","receivedAt":"2021-06-26T07:55:46Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Marco,\n\nOn Fri, Jun 25, 2021 at 12:15 AM Marco Giuliano\n<marco.giuliano@tesisquare.com> wrote:\n>\n> Hi Philip,\n> oh, so I guessed correctly...\n> Could you be more specific about the copy/rename issue of the apply backend ?\n> Is there any bug report I can refer to ?\n>\n> Thank you very much for your support\n\nCould you do us a favor?  Please avoid top-posting and instead answer\nafter the quoted original text, much like I'll do here...\n\n> On Thu, Jun 24, 2021 at 8:39 PM Phillip Wood <phillip.wood123@gmail.com> wrote:\n> >\n> > Hi Marco\n> >\n> > On 24/06/2021 17:23, Marco Giuliano wrote:\n> > > Thanks Felipe and Philip for your answers.\n> > >\n> > > Let's proceed in order:\n> > > @Felipe: I tried rebasing with --no-fork-point but the problem remains the same\n> > >\n> > > @Philip:\n> > > I'm a basic git user, so bear with me if I say silly things...\n> > > I tried to search for rebased-patches in .git folder when rebase\n> > > stopped waiting for\n> > > conflict resolution, but I didn't find any file named like that.\n> > > There's a folder named rebase-apply though did you mean that ?\n> >\n> > Looking at the source I thought they ended up just in .git but I haven't\n> > checked again, as you seem to have found the source of the problem below\n> > lets not worry about that.\n> >\n> > > Anyway, looking at the conflict file of \"fileA\" directly (not behind a\n> > > visual diff tool) I noticed that the marker line >>>>>>>> COMMIT\n> > > DESCR: FILENAME indicates a different file name then the current\n> > > conflicted file.\n> > > That reminded me that those two files A & B, were actually copies\n> > > (real copy, not symlink) of other two files inside the same repo.\n> > > Is it somehow possible that auto-detected-renaming is involved in this\n> > > (since the files are identical but in two different locations) ?\n> > > Trying to give you some hints, maybe it is totally unrelated...\n> >\n> > I meant to ask if anything had been copied or renamed but forgot. The\n> > merge backend detects copies and renames and handles them correctly but\n> > the apply backend does not so I think this is the source of the discrepancy.\n> >\n\nSo I've got a hunch here.  First, Marco, from your example, can you run\n\ngit diff --name-status -C Y...X\n\nand report whether the files involved were either renamed or copied on\nthe upstream side of history.  (Also, please note that there are three\ndots between Y and X)  Also, can you report whether a message of the\nform \"inexact rename detection was skipped due to too many files\" when\nusing the merge backend and that files you copied from end up in\nmodify/delete conflicts when using the merge backend?\n\n\nMy suspicion is:\n* You both renamed some files and copied them on the upstream side of history\n* You made further changes to the renamed files, more so than to the \"copies\"\n* You have enough added/removed/renamed files that with the merge\nbackend you are triggering merge.renameLimit and not getting rename\ndetection, causing various reports of modify/delete conflicts\n* The apply backend's use of fake trees can be viewed as a poor-man's\nversion of the irrelevant rename detection optimization I added to\nmerge-ort, but it works well enough to get you under merge.renameLimit\nso that renames are detected for the apply backend\n* The fact that you modified what you view as renames more than what\nyou viewed as copies has the perverse effect of causing git's rename\ndetection to pair up files with the copy rather than the rename, and\napply changes to it\n\nThe net result is that the 'merge' backend isn't apply your changes\nfrom various files to their renamed counterpart, while the 'apply'\nbackend is almost doing that but applying them to what you think of as\nthe copy rather than the intended renamed file.  The questions I asked\nabove may be able to help us either confirm or rule out this theory.\n"},{"id":"428765","messageId":"CANLwWg7Y4yH=yQYt3d7xH-LDfiZgbiMpHb9uxSJ=xT12s2WnrQ@mail.gmail.com","threadId":"55959","inReplyTo":"CABPp-BH1COE8worEAuu3M_LNJfVhW3Y6+1r8zfUcVaTrVgjG5w@mail.gmail.com","subject":"Re: Nonexistent changes appear rebasing but only with rebase.backend=apply","fromName":"Marco Giuliano","fromEmail":"marco.giuliano@tesisquare.com","sentAt":"2021-06-29T18:58:21Z","receivedAt":"2021-06-29T18:58:52Z","isPatch":false,"sender":{"key":"marco.giuliano@tesisquare.com","avatar":null},"body":"On Sat, Jun 26, 2021 at 9:53 AM Elijah Newren <newren@gmail.com> wrote:\n>\n> Hi Marco,\n>\n> On Fri, Jun 25, 2021 at 12:15 AM Marco Giuliano\n> <marco.giuliano@tesisquare.com> wrote:\n> >\n> > Hi Philip,\n> > oh, so I guessed correctly...\n> > Could you be more specific about the copy/rename issue of the apply backend ?\n> > Is there any bug report I can refer to ?\n> >\n> > Thank you very much for your support\n>\n> Could you do us a favor?  Please avoid top-posting and instead answer\n> after the quoted original text, much like I'll do here...\n>\n> > On Thu, Jun 24, 2021 at 8:39 PM Phillip Wood <phillip.wood123@gmail.com> wrote:\n> > >\n> > > Hi Marco\n> > >\n> > > On 24/06/2021 17:23, Marco Giuliano wrote:\n> > > > Thanks Felipe and Philip for your answers.\n> > > >\n> > > > Let's proceed in order:\n> > > > @Felipe: I tried rebasing with --no-fork-point but the problem remains the same\n> > > >\n> > > > @Philip:\n> > > > I'm a basic git user, so bear with me if I say silly things...\n> > > > I tried to search for rebased-patches in .git folder when rebase\n> > > > stopped waiting for\n> > > > conflict resolution, but I didn't find any file named like that.\n> > > > There's a folder named rebase-apply though did you mean that ?\n> > >\n> > > Looking at the source I thought they ended up just in .git but I haven't\n> > > checked again, as you seem to have found the source of the problem below\n> > > lets not worry about that.\n> > >\n> > > > Anyway, looking at the conflict file of \"fileA\" directly (not behind a\n> > > > visual diff tool) I noticed that the marker line >>>>>>>> COMMIT\n> > > > DESCR: FILENAME indicates a different file name then the current\n> > > > conflicted file.\n> > > > That reminded me that those two files A & B, were actually copies\n> > > > (real copy, not symlink) of other two files inside the same repo.\n> > > > Is it somehow possible that auto-detected-renaming is involved in this\n> > > > (since the files are identical but in two different locations) ?\n> > > > Trying to give you some hints, maybe it is totally unrelated...\n> > >\n> > > I meant to ask if anything had been copied or renamed but forgot. The\n> > > merge backend detects copies and renames and handles them correctly but\n> > > the apply backend does not so I think this is the source of the discrepancy.\n> > >\n>\n> So I've got a hunch here.  First, Marco, from your example, can you run\n>\n> git diff --name-status -C Y...X\n>\n> and report whether the files involved were either renamed or copied on\n> the upstream side of history.  (Also, please note that there are three\n> dots between Y and X)  Also, can you report whether a message of the\n> form \"inexact rename detection was skipped due to too many files\" when\n> using the merge backend and that files you copied from end up in\n> modify/delete conflicts when using the merge backend?\n>\n>\n> My suspicion is:\n> * You both renamed some files and copied them on the upstream side of history\n> * You made further changes to the renamed files, more so than to the \"copies\"\n> * You have enough added/removed/renamed files that with the merge\n> backend you are triggering merge.renameLimit and not getting rename\n> detection, causing various reports of modify/delete conflicts\n> * The apply backend's use of fake trees can be viewed as a poor-man's\n> version of the irrelevant rename detection optimization I added to\n> merge-ort, but it works well enough to get you under merge.renameLimit\n> so that renames are detected for the apply backend\n> * The fact that you modified what you view as renames more than what\n> you viewed as copies has the perverse effect of causing git's rename\n> detection to pair up files with the copy rather than the rename, and\n> apply changes to it\n>\n> The net result is that the 'merge' backend isn't apply your changes\n> from various files to their renamed counterpart, while the 'apply'\n> backend is almost doing that but applying them to what you think of as\n> the copy rather than the intended renamed file.  The questions I asked\n> above may be able to help us either confirm or rule out this theory.\n\n\nHi Elijah,\nsorry for the top posting.\n\nI tried the 3-dots command, but no changes on those 2 files are\nreported. Neither I got any message about inexact rename detection\nusing the merge backend.\n\nI think it might be something related to copy/rename/slighly-change\nvery similar files, but probably not exactly what you described.\nCommit 4 is the result of a squash where I remember doing changes and\ncopies of those two files, is it possible that the squash operation\n(which uses rebase under the hood) somehow nullified some of those\nchanges because of their similarities and the current rebase-apply\nmade them reappear ?\n\nI don't know if it can be useful, but if I do an interactive rebase\n(rebase -i X), even with rebase.backend=apply, the two files do not\nappear among the conflicts (same as rebase.backend=merge).\n\nThanks for the support\nMarco\n"}]}