Discussion:
git-cherry-pick no longer detecting moved files in 1.5.3.4
Richard Quirk
2007-10-16 22:17:00 UTC
Permalink
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
2007-10-16 22:35:12 UTC
Permalink
Post by Richard Quirk
I tried setting diff.renamelimit to -1 but to no
avail.
It should be
diff.renamelimit = 0

to set the "unlimited" limit.
Richard Quirk
2007-10-17 07:18:25 UTC
Permalink
Post by Michele Ballabio
Post by Richard Quirk
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
2007-10-17 07:33:57 UTC
Permalink
Post by Richard Quirk
Post by Michele Ballabio
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
2007-10-17 07:55:13 UTC
Permalink
Post by Shawn O. Pearce
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
2007-10-17 00:58:56 UTC
Permalink
Post by Richard Quirk
(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.
Loading...