All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
	Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH] merge-ort: avoid assuming all renames detected
Date: Sun, 16 Jan 2022 13:46:40 -0800	[thread overview]
Message-ID: <xmqqczkr1hhb.fsf@gitster.g> (raw)
In-Reply-To: <pull.1194.git.git.1642212566346.gitgitgadget@gmail.com> (Elijah Newren via GitGitGadget's message of "Sat, 15 Jan 2022 02:09:26 +0000")

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Elijah Newren <newren@gmail.com>
>
> In commit 8b09a900a1 ("merge-ort: restart merge with cached renames to
> reduce process entry cost", 2021-07-16), we noted that in the merge-ort
> steps of
>     collect_merge_info()
>     detect_and_process_renames()
>     process_entries()
> that process_entries() was expensive, and we could often make it cheaper
> by changing this to
>     collect_merge_info()
>     detect_and_process_renames()
>     <cache all the renames, and restart>
>     collect_merge_info()
>     detect_and_process_renames()
>     process_entries()
> because the second collect_merge_info() would be cheaper (we could avoid
> traversing into some directories), the second
> detect_and_process_renames() would be free since we had already detected
> all renames, and then process_entries() has far fewer entries to handle.
>
> However, this was built on the assumption that the first
> detect_and_process_renames() actually detected all potential renames.
> If someone has merge.renameLimit set to some small value, that
> assumption is violated which manifests later with the following message:
>
>     $ git -c merge.renameLimit=1 rebase upstream
>     ...
>     git: merge-ort.c:546: clear_or_reinit_internal_opts: Assertion
>     `renames->cached_pairs_valid_side == 0' failed.
>
> Turn off this cache-renames-and-restart whenever we cannot detect all
> renames, and add a testcase that would have caught this problem.
>
> Reported-by: Taylor Blau <me@ttaylorr.com>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---

Thanks.  Will fork from maint-2.33 and park on 'seen' for now.

  reply	other threads:[~2022-01-16 21:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-15  2:09 [PATCH] merge-ort: avoid assuming all renames detected Elijah Newren via GitGitGadget
2022-01-16 21:46 ` Junio C Hamano [this message]
2022-01-16 23:19 ` Junio C Hamano
2022-01-17 18:25 ` [PATCH v2] " Elijah Newren via GitGitGadget
2022-01-17 19:33   ` Junio C Hamano
2022-01-17 21:21     ` Elijah Newren
2022-01-17 22:07       ` Taylor Blau
2022-01-17 22:23         ` Junio C Hamano
2022-01-17 22:16       ` Junio C Hamano
2022-06-30  9:53   ` SZEDER Gábor
2022-07-01  2:30     ` Elijah Newren
2022-07-01  5:21       ` Elijah Newren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqczkr1hhb.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.