Re: merge-ort assertion failure

From: Taylor Blau <me@ttaylorr.com>
Date: Jan 14, 2022, 22:29 UTC
Message-ID: <YeH5OSG0RW29REhn@nand.local>
In-Reply-To: <CABPp-BFM+fU+jVJwrU4ooPGvHbw859M+RNb+MvJe12MPV_=q7g@mail.gmail.com>

On Fri, Jan 14, 2022 at 02:15:31PM -0800, Elijah Newren wrote:

Show 10 quoted lines

> On Fri, Jan 14, 2022 at 11:46 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> > I haven't had a chance to look into it very deeply yet. Elijah: I figure
> > that this is the sort of thing that may be totally obvious to you, so
> > I'm sharing it here in case it is.
>
> I don't have a testcase (though I think there is probably enough
> information here for me to create one), but I think I know the
> problem.  Does this fix it for you? :
> https://github.com/git/git/pull/1193

Unfortunately not. With a sufficiently small value of merge.renameLimit (in my case, just 1) I can trigger the same assertion failure:

    $ GIT_DEBUGGER=1 git.compile -c merge.renameLimit=1 rebase $onto
    [...]
    Thread 1 "git" hit Breakpoint 1, clear_or_reinit_internal_opts (opti=0x55555b0cf3f0, reinitialize=0) at merge-ort.c:546
    546				assert(renames->cached_pairs_valid_side == 0);
    (gdb) p renames->cached_pairs_valid_side
    $1 = -1

Short of providing a small, reproducible test-case, I'm happy to share any information I can about the repository that might be useful to you.

Thanks, Taylor