Thread (4 messages) flat view 4 messages, 3 authors, 2016-06-15

Re: [PATCH] Add --no-rename to git-apply

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:36

Robin Rosenberg [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help