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

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

[Richard Quirk]

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

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

[Michele Ballabio]

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.

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

[Shawn O. Pearce]

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.

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

[Richard Quirk]

On 10/17/07, Michele Ballabio <barra_cuda@katamail.com> wrote:
> 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.

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

[Shawn O. Pearce]

Richard Quirk <richard.quirk@gmail.com> wrote:
> 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.

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

[Richard Quirk]

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!