threads / discuss / 10325

git-cherry-pick no longer detecting moved files in 1.5.3.4

Subject: git-cherry-pick no longer detecting moved files in 1.5.3.4

## tl;dr

6 messages between Oct 16, 2007 and Oct 17, 2007.

replies: 5people: 3as markdown or json

Richard Quirk· Oct 16, 2007, 22:17 UTC · lore

I recently upgraded from git 1.5.3 to 1.5.3.4 and my cherry picks from path/to/file.c to path/to/subdir/file.c stopped working. The error being:

CONFLICT (delete/modify): path/to/file.c deleted in HEAD and modified in 9f944cb... <commit msg> Version 9f944cb... <commit msg> of path/to/file.c left in tree.

The history of my project is that I had an extra sub directory that I got rid of, moving files up a level on the master branch but this extra directory is still present on a "release" branch. It is to this release branch that I am cherry picking changes from the master one. This worked fine in 1.5.4.

I tracked the change that scuppered my cherry picking down to this fix by Linus for rename detection limits: http://git.kernel.org/?p=git/git.git;a=commit;h=0024a54923a12

Seems like I hit the limit there - the moving changed the location of about 140 files. I tried setting diff.renamelimit to -1 but to no avail. Is it that the config value only applies for git-diff, not git-cherry-pick? (Also, minor thing this, but the docs for git-config says it is diff.renameLimit but diff.c uses diff.renamelimit.) Recompiling with diff_rename_limit_default set to -1 in diff.c "fixes" the cherry picking, but isn't ideal. Anyone have any ideas for a better workaround/fix?

thanks, Richard

Michele Ballabio· Oct 16, 2007, 22:35 UTC · re: Richard Quirk · lore

Re: git-cherry-pick no longer detecting moved files in 1.5.3.4

On Wednesday 17 October 2007, Richard Quirk wrote:
> I tried setting diff.renamelimit to -1 but to no
> avail.

It should be diff.renamelimit = 0

to set the "unlimited" limit.
Richard Quirk· Oct 17, 2007, 07:18 UTC · re: Michele Ballabio · lore

Re: git-cherry-pick no longer detecting moved files in 1.5.3.4

On 10/17/07, Michele Ballabio <barra_cuda@katamail.com> wrote:
Show 9 quoted lines
> On Wednesday 17 October 2007, Richard Quirk wrote:
> > I tried setting diff.renamelimit to -1 but to no
> > avail.
>
> It should be
> diff.renamelimit = 0
>
> to set the "unlimited" limit.
>

This doesn't work either. Cherry picking is not triggering the loading of this value at all.

This is because git-cherry-pick turns into a git-merge-recursive. This calls get_renames() in merge-recursive.c, which calls diff_setup, setting the renamelimit to -1, then calls diff_setup_done(), which sets the renamelimit to diff_rename_limit_default since rename_limit was < 0. diff_rename_limit_default is the hard-coded value of 100. At no point does merge-recursive call git_diff_ui_config() in diff.c that reads in the diff.renamelimit user defined value, so in the end the cherry pick uses the hardcoded value of 100.

Shawn O. Pearce· Oct 17, 2007, 07:33 UTC · re: Richard Quirk · lore

Re: git-cherry-pick no longer detecting moved files in 1.5.3.4

Richard Quirk <richard.quirk@gmail.com> wrote:
Show 18 quoted lines
> On 10/17/07, Michele Ballabio <barra_cuda@katamail.com> wrote:
> > It should be
> > diff.renamelimit = 0
> >
> > to set the "unlimited" limit.
> >
> 
> This doesn't work either. Cherry picking is not triggering the loading
> of this value at all.
> 
> This is because git-cherry-pick turns into a git-merge-recursive. This
> calls get_renames() in merge-recursive.c, which calls diff_setup,
> setting the renamelimit to -1, then calls diff_setup_done(), which
> sets the renamelimit to diff_rename_limit_default since rename_limit
> was < 0. diff_rename_limit_default is the hard-coded value of 100. At
> no point does merge-recursive call git_diff_ui_config() in diff.c that
> reads in the diff.renamelimit user defined value, so in the end the
> cherry pick uses the hardcoded value of 100.

That's an "old" bug. Lars Hjemli fixed this in df3a02f612 back on Sept 25th. You can get the fix from either Junio's or my git tree in the master branch.

-- 
Shawn.
Richard Quirk· Oct 17, 2007, 07:55 UTC · re: Shawn O. Pearce · lore

Re: git-cherry-pick no longer detecting moved files in 1.5.3.4

On 10/17/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>
> That's an "old" bug.  Lars Hjemli fixed this in df3a02f612 back on
> Sept 25th.  You can get the fix from either Junio's or my git tree
> in the master branch.

Yes, with that fix setting the diff.renamelimit config value to 0 really does work. Thanks!

Shawn O. Pearce· Oct 17, 2007, 00:58 UTC · re: Richard Quirk · lore

Re: git-cherry-pick no longer detecting moved files in 1.5.3.4

Richard Quirk <richard.quirk@gmail.com> wrote:
> (Also, minor thing this, but the docs for git-config
> says it is diff.renameLimit but diff.c uses diff.renamelimit.)

Someone else already responded about how to set this limit, but I wanted to clarify what the docs vs. the code were doing here.

The docs use camelCase as it is prettier to read multiple words that useCamelCase than alllowercaselikethis. Internally when we parse your config file we lowercase the entire string so that the code can worry only about the lowercase variant. That's why you see it all lowercase in diff.c, but the docs suggest you to use the camelCase format.

-- 
Shawn.

← back to recent threads