Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> writes: > With this option git-apply can apply a patch with a rename > onto the original file(s). This is troubling from both design and implementation point of view. * Why would this be useful? What's the point of producing the renaming patch if you know you would want to apply while ignoring the rename? * The change looks too special purpose to me. If you are giving the ability to deposit the result to somewhere other than where the patch intendes to, why limit it only to the preimage name? Aren't there cases where A is renamed to B sometime in the history, and you have a patch that talks about the content change A->A but the tree you have has the contents already in B, and you would want to apply that patch? It feels that this and your "ignore rename" could be handled much more cleanly and flexibly by preprocessing the patchfile. * By disabling the parsing of rename header lines, you are disabling the sanity checking of the input done in gitdiff_verify_name() called from gitdiff_oldname() and gitdiff_newname(). I think it is wrong for --no-rename option to affect the parsing of the input. If we were to do this, perhaps write_out_results() or one of its callee would be a better place to do so. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
