{"thread":{"id":"57248","subject":"merge-ort assertion failure","startedAt":"2022-01-14T19:46:44Z","lastAt":"2022-01-14T22:29:16Z","messageCount":3,"participants":["Taylor Blau","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"446242","messageId":"YeHTIfEutLYM4TIU@nand.local","threadId":"57248","inReplyTo":null,"subject":"merge-ort assertion failure","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-01-14T19:46:41Z","receivedAt":"2022-01-14T19:46:44Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Elijah,\n\nA colleague reported that they were able to hit an assertion failure in\nmerge-ort when rebasing a topic of their back onto upstream.\n\nThe scenario (which I have been able to reproduce on a private\nrepository, but haven't had time to reduce further) is:\n\n    $ git --version\n    git version 2.34.1\n\n    $ git rebase origin/master\n    warning: skipped previously applied commit 9cda243afc2a\n    warning: skipped previously applied commit 882bb87a3a7c\n    hint: use --reapply-cherry-picks to include skipped commits\n    hint: Disable this message with \"git config advice.skippedCherryPicks false\"\n    [some \"Auto-merging\" messages ...]\n    CONFLICT (content): Merge conflict in\n    [some file]\n    warning: exhaustive rename detection was skipped due to too many files.\n    warning: you may want to set your merge.renamelimit variable to at least 165 and retry the command.\n    Assertion failed: (renames->cached_pairs_valid_side == 0), function\n    clear_or_reinit_internal_opts, file merge-ort.c, line 546.\n    Abort trap: 6\n\nTheir merge.renameLimit is set pretty low at just \"1\", and this\nassertion goes away so long as `merge.renameLimit` is set sufficiently\nhigh.\n\nI haven't had a chance to look into it very deeply yet. Elijah: I figure\nthat this is the sort of thing that may be totally obvious to you, so\nI'm sharing it here in case it is.\n\nOtherwise, I'll continue to poke at it locally and see if I can learn\nanything else.\n\nThanks,\nTaylor\n"},{"id":"446259","messageId":"CABPp-BFM+fU+jVJwrU4ooPGvHbw859M+RNb+MvJe12MPV_=q7g@mail.gmail.com","threadId":"57248","inReplyTo":"YeHTIfEutLYM4TIU@nand.local","subject":"Re: merge-ort assertion failure","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2022-01-14T22:15:31Z","receivedAt":"2022-01-14T22:15:48Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jan 14, 2022 at 11:46 AM Taylor Blau <me@ttaylorr.com> wrote:\n>\n> Elijah,\n>\n> A colleague reported that they were able to hit an assertion failure in\n> merge-ort when rebasing a topic of their back onto upstream.\n>\n> The scenario (which I have been able to reproduce on a private\n> repository, but haven't had time to reduce further) is:\n>\n>     $ git --version\n>     git version 2.34.1\n>\n>     $ git rebase origin/master\n>     warning: skipped previously applied commit 9cda243afc2a\n>     warning: skipped previously applied commit 882bb87a3a7c\n>     hint: use --reapply-cherry-picks to include skipped commits\n>     hint: Disable this message with \"git config advice.skippedCherryPicks false\"\n>     [some \"Auto-merging\" messages ...]\n>     CONFLICT (content): Merge conflict in\n>     [some file]\n>     warning: exhaustive rename detection was skipped due to too many files.\n>     warning: you may want to set your merge.renamelimit variable to at least 165 and retry the command.\n>     Assertion failed: (renames->cached_pairs_valid_side == 0), function\n>     clear_or_reinit_internal_opts, file merge-ort.c, line 546.\n>     Abort trap: 6\n>\n> Their merge.renameLimit is set pretty low at just \"1\", and this\n> assertion goes away so long as `merge.renameLimit` is set sufficiently\n> high.\n>\n> I haven't had a chance to look into it very deeply yet. Elijah: I figure\n> that this is the sort of thing that may be totally obvious to you, so\n> I'm sharing it here in case it is.\n\nI don't have a testcase (though I think there is probably enough\ninformation here for me to create one), but I think I know the\nproblem.  Does this fix it for you? :\nhttps://github.com/git/git/pull/1193\n"},{"id":"446261","messageId":"YeH5OSG0RW29REhn@nand.local","threadId":"57248","inReplyTo":"CABPp-BFM+fU+jVJwrU4ooPGvHbw859M+RNb+MvJe12MPV_=q7g@mail.gmail.com","subject":"Re: merge-ort assertion failure","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-01-14T22:29:13Z","receivedAt":"2022-01-14T22:29:16Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Fri, Jan 14, 2022 at 02:15:31PM -0800, Elijah Newren wrote:\n> On Fri, Jan 14, 2022 at 11:46 AM Taylor Blau <me@ttaylorr.com> wrote:\n>\n> > I haven't had a chance to look into it very deeply yet. Elijah: I figure\n> > that this is the sort of thing that may be totally obvious to you, so\n> > I'm sharing it here in case it is.\n>\n> I don't have a testcase (though I think there is probably enough\n> information here for me to create one), but I think I know the\n> problem.  Does this fix it for you? :\n> https://github.com/git/git/pull/1193\n\nUnfortunately not. With a sufficiently small value of merge.renameLimit\n(in my case, just 1) I can trigger the same assertion failure:\n\n    $ GIT_DEBUGGER=1 git.compile -c merge.renameLimit=1 rebase $onto\n    [...]\n    Thread 1 \"git\" hit Breakpoint 1, clear_or_reinit_internal_opts (opti=0x55555b0cf3f0, reinitialize=0) at merge-ort.c:546\n    546\t\t\t\tassert(renames->cached_pairs_valid_side == 0);\n    (gdb) p renames->cached_pairs_valid_side\n    $1 = -1\n\nShort of providing a small, reproducible test-case, I'm happy to share\nany information I can about the repository that might be useful to you.\n\nThanks,\nTaylor\n"}]}