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

torsdag 27 september 2007 skrev Junio C Hamano:

Robin Rosenberg [off-list ref] writes:

quoted

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 point of producing the rename info is to find out which renames
are in it. It's only that I don't want to perform them straight away.

 * 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.

Well it is special *purpose*, but not tied to a particuar tool. I'm
not sure whether it is necessary with other tools though. I'll
consider the preprocessing and will retry the rename-back that
Johannes suggested.

 * 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.

Hopefully git produces sane things so the checking shouldn't be that
important, but I also do a check before beginning with checkouts and
so on, much like git-cvsexportcommit. The check  is performed without
the switch.

-- robin