torsdag 27 september 2007 skrev Junio C Hamano: > 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 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 - 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
