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

Re: Bugs with detection of renames that are also overwrites

From
Jeff King <peff@peff.net>
Date
Feb 23, 2010, 12:59 UTC
Message-ID
<20100223125952.GA7638@coredump.intra.peff.net>
In-Reply-To
<2cfc40321002230453q3a593fa6l43850207ebddfc99@mail.gmail.com>
On Tue, Feb 23, 2010 at 11:53:13PM +1100, Jon Seymour wrote:
> I came across a similar case recently while testing my rebasing ideas
> which lead me to wonder - is there a way to suppress the rename and
> overwrite detection? For my purposes, I don't care if the diff is
> bulky, I just want it to apply reliably.

For diff generation, it should be off by default (but you may have configured diff.renames, in which case you can pass --no-renames to suppress it).

For the merge-recursive driver, it is on by default. You can hack it off by setting merge.renamelimit to something small like '1' (but don't use '0', which means "no limit"). Rebase uses "git am -3" internally, which in turn invokes merge-recursive.

-Peff
Previous: Jon SeymourNext: Anders Kaseorg
Message 4 of 5 in “Bugs with detection of renames that are also overwrites”
  1. Anders KaseorgFeb 13, 2010
  2. Jeff KingFeb 23, 2010
  3. Jon SeymourFeb 23, 2010
  4. Jeff KingFeb 23, 2010
  5. Anders KaseorgFeb 23, 2010

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.