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

Re: limiting rename detection during merge is a really bad idea

From
Jeff King <peff@peff.net>
Date
Feb 11, 2008, 11:08 UTC
Message-ID
<20080211110816.GA6344@coredump.intra.peff.net>
In-Reply-To
<8c5c35580802110241i72169620s693a31f9a098f596@mail.gmail.com>
On Mon, Feb 11, 2008 at 11:41:05AM +0100, Lars Hjemli wrote:
Show 8 quoted lines
> > It may also be that multiple rename limits are appropriate. I don't mind
> > waiting 30 seconds for rename detection during a particularly tricky
> > merge. I probably do when running 'git-log -p'.
> 
> Yeah, I guess we could add support for merge.renamelimit in addition
> to diff.renamelimit (i.e. use diff.renamelimit if merge.renamelimit is
> unspecified). And/or add the -l option of git-diff-* to
> git-merge.sh/merge-recursive.c.

Perhaps we should first figure out what reasonable default values are. I think the reported problem was not "Oh, I didn't expect my tweaked diff.renamelimit to affect merge" but rather "I didn't tweak diff.renamelimit at all".

The mega-commit I was playing with that caused Linus to suggest diff.renamelimit in the first place is 374 by 641 (src by dest) and completes in ~15 minutes. The case recently reported in "git-revert is a memory hog" is 3541 by 8043, and doesn't complete ever. We limit to 100 by 100 by default.

Steffen, can you tell us how large your rename set is (unfortunately, there is no way to get this information easily; you can stop merge-recursive in the debugger at diffcore-rename.c:457 and look at num_src and num_create). And how long it takes to run with diff.renamelimit turned off?

That might give us a clue where a reasonable value is.
-Peff
Previous: Lars HjemliNext: Santi Béjar
Message 7 of 11 in “limiting rename detection during merge is a really bad idea”
  1. Steffen ProhaskaFeb 11, 2008
  2. Marco CostalbaFeb 11, 2008
  3. Jeff KingFeb 11, 2008
  4. Marco CostalbaFeb 11, 2008
  5. Jeff KingFeb 11, 2008
  6. Lars HjemliFeb 11, 2008
  7. Jeff KingFeb 11, 2008
  8. Santi BéjarFeb 11, 2008
  9. Jeff KingFeb 11, 2008
  10. Steffen ProhaskaFeb 11, 2008
  11. Jeff KingFeb 11, 2008

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.