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.
Hi,
On Wed, 26 Sep 2007, Junio C Hamano wrote:
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?
Robin said in a follow-up mail that he needs it for a payed-for SCM
(let's describe it as TransparentBox here), which insists on explicit
renames.
But I suggest a simple script here which extracts from the diff the
renames, which outputs a script which renames the file(s) back and then
uses the TransparentBox' mv command:
sed -n -e "/^rename from/N" \
-e "s/^rename from \(.*\)\nrename to \(.*\)/mv \2 \1 \&\& tb mv \1 \2/p" \
< diff.patch
Ciao,
Dscho
torsdag 27 september 2007 skrev Johannes Schindelin:
Robin said in a follow-up mail that he needs it for a payed-for SCM
(let's describe it as TransparentBox here), which insists on explicit
renames.
But I suggest a simple script here which extracts from the diff the
renames, which outputs a script which renames the file(s) back and then
uses the TransparentBox' mv command:
sed -n -e "/^rename from/N" \
-e "s/^rename from \(.*\)\nrename to \(.*\)/mv \2 \1 \&\& tb mv \1 \2/p" \
< diff.patch
I tried something like that (integrated in the script), and the bugger noticed
it and refused to work as exepected, but now that I think about it should be
possible to fool it. I have to give it a go again and see what really actually
went wrong.
-- robin
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