Ben Peart <peart...@gmail.com> writes: > Color me puzzled. :) The consensus was that the default value for > merge.renames come from diff.renames. diff.renames supports copy > detection which means that merge.renames will inherit that value. My > assumption was that is what was intended so when I reimplemented it, I > fully implemented it that way. > > Are you now requesting to only use diff.renames as the default if the > value is true or false but not if it is copy? What should happen if > diff.renames is actually set to copy? Should merge silently change > that to true, display a warning, error out, or something else? Do you > have some other behavior for how to handle copy being inherited from > diff.renames you'd like to see? > > Can you write the documentation that clearly explains the exact > behavior you want? That would kill two birds with one stone... :)
I think demoting from copy to rename-only is a good idea, at least for now, because I do not believe we have figured out what we want to happen when we detect copied files are involved in a merge. But I am not sure if we even want to fail merge.renames=copy as an invalid configuration. So my gut feeling of the best solution to the above is to do something like: - whether the configuration comes from diff.renames or merge.renames, turn *.renames=copy to true inside the merge recursive machinery. - document the fact in "git merge-recursive" documentation (or "git merge" documentation) to say "_currently_ asking for rename detection to find copies and renames will do the same thing---copies are ignored", impliying "this might change in the future", in the BUGS section.
