git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/4] sequencer: Warn when internal merge may be suboptimal due to renameLimit

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 13, 2017, 05:16 UTC
Message-ID
<xmqqy3na92rv.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20171110173956.25105-2-newren@gmail.com>
Elijah Newren <newren@gmail.com> writes:
> Subject: Re: [PATCH 1/4] sequencer: Warn when internal merge may be suboptimal due to renameLimit
Style: please downcase s/Warn/warn/ to fit this better in "shortlog --no-merges"
output.
Show 5 quoted lines
> Having renamed files silently treated as deleted/modified conflicts
> instead of correctly resolving the renamed/modified case has caused lots
> of pain for some users.  Eventually, some of them figured out to set
> merge.renameLimit to something higher, but without feedback about what
> value it should have, they were just repeatedly guessing and retrying.

It would have been _much_ easier to read if you refrained from stating the gripes more prominently than the source of the gripe that you are fixing. E.g.

	If one side of a merge have renamed more paths than
	merge.renamelimit since the sides diverged, the recursive
	merge strategy stops detecting renames and instead leaves
	these many paths as delete/modify conflicts, without warning
	what is going on and giving hints on how to tell Git that it
	is allowed to spend more cycles to detect renames.
perhaps.

The addition of a call to diff_warn_rename_limit looks quite sensible.

Thanks.
Show 16 quoted lines
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  sequencer.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/sequencer.c b/sequencer.c
> index f2a10cc4f2..2b4cecb617 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -462,6 +462,7 @@ static int do_recursive_merge(struct commit *base, struct commit *next,
>  	if (is_rebase_i(opts) && clean <= 0)
>  		fputs(o.obuf.buf, stdout);
>  	strbuf_release(&o.obuf);
> +	diff_warn_rename_limit("merge.renamelimit", o.needed_rename_limit, 0);
>  	if (clean < 0)
>  		return clean;
Previous: Elijah NewrenNext: Elijah Newren
Message 13 of 15 in “Fix issues with rename detection limits”
  1. 0/4 Fix issues with rename detection limitsElijah Newren, Nov 10, 2017
  2. 2/4 Remove silent clamp of renameLimitElijah Newren, Nov 10, 2017
  3. Stefan BellerNov 10, 2017
  4. Elijah NewrenNov 10, 2017
  5. brian m. carlsonNov 10, 2017
  6. Elijah NewrenNov 11, 2017
  7. brian m. carlsonNov 11, 2017
  8. 3/4 progress: Fix progress meters when dealing with lots of workElijah Newren, Nov 10, 2017
  9. Junio C HamanoNov 13, 2017
  10. Elijah NewrenNov 13, 2017
  11. Junio C HamanoNov 14, 2017
  12. 1/4 sequencer: Warn when internal merge may be suboptimal due to renameLimitElijah Newren, Nov 10, 2017
  13. Junio C HamanoNov 13, 2017
  14. 4/4 sequencer: Show rename progress during cherry picksElijah Newren, Nov 10, 2017
  15. Junio C HamanoNov 13, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.