Re: [PATCH] Add --patchdepth parameter to git-am.sh

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] Add --patchdepth parameter to git-am.sh

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:53

Andy Parkins [off-list ref] writes:
If the series of patches you are applying via git-am was based in a
different directory there was no way to strip the directory (as you
would with git-apply).

This patch adds a --patchdepth option to git-am.sh whose argument is
passed as a "-p" option to git-apply.

Signed-off-by: Andy Parkins <redacted>
---
I know git-apply isn't going anywhere, but git-applypatch is.  However, all
this talk of it made me remember this patch.
I do not understand this remark, as applypatch does not have -p
either.  If we were to do this, I agree with others that this
should simply be called -p (we do not have name crash with
existing options, do we?).

I am not sure how useful applying a patch though git-am with -p
would be.  I can understand, 

After seeing that a patch does not apply because the patch was
generated at the wrong level, it would be very natural to use
"git apply -p0 --index .dotest/patch" and then continue with
"git am --resolved".  So obviously, -p to git-apply is very
useful, but -p given to "am" means all of the patches in your
mailbox has uniformly wrong patch depth.  I wonder how common
would that be in practice.

But other than that "how useful would that be in practice?"
issue, I do not think the patch is too bad, except one hunk:
quoted hunk
@@ -389,12 +392,12 @@ do
 	fi
 
 	echo
-	echo "Applying '$SUBJECT'"
+	echo "Applying '$SUBJECT' at depth $patchdepth"
 	echo
 
This is wrong if you do not use any $patchdepth.

Re: [PATCH] Add --patchdepth parameter to git-am.sh

From: Jakub Narebski <hidden>
Date: 2016-06-15 22:42:53

Junio C Hamano wrote:
Andy Parkins [off-list ref] writes:
quoted
If the series of patches you are applying via git-am was based in a
different directory there was no way to strip the directory (as you
would with git-apply).

This patch adds a --patchdepth option to git-am.sh whose argument is
passed as a "-p" option to git-apply.
[...]
I do not understand this remark, as applypatch does not have -p
either.  If we were to do this, I agree with others that this
should simply be called -p (we do not have name crash with
existing options, do we?).
Perhaps options should be -p as short version, and --patchdepth 
(or --strip as in GNU patch) as long version?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] Add --patchdepth parameter to git-am.sh

From: Andy Parkins <hidden>
Date: 2016-06-15 22:42:53

On Wednesday 2007 February 07 08:27, Junio C Hamano wrote:
I do not understand this remark, as applypatch does not have -p
either.  If we were to do this, I agree with others that this
Oh.  That /would/ make it confusing.  I didn't realise they both didn't have 
it (I thought I had used it at some point in the past, my swiss cheese 
memory).  In that case, the patch is a lot more relevant.
should simply be called -p (we do not have name crash with
existing options, do we?).
I have no problem with it being "-p"; I just don't like to take valuable 
single letter namespace unilaterally.
After seeing that a patch does not apply because the patch was
generated at the wrong level, it would be very natural to use
"git apply -p0 --index .dotest/patch" and then continue with
"git am --resolved".  So obviously, -p to git-apply is very
useful, but -p given to "am" means all of the patches in your
mailbox has uniformly wrong patch depth.  I wonder how common
would that be in practice.
I added it because I had need for it; I managed to manufacture a whole series 
of patches at the wrong patch level.  It had been hard work to make them, so 
I didn't feel like making them all again just to change the depth.
But other than that "how useful would that be in practice?"
This is wrong if you do not use any $patchdepth.
Guilty.  As I said, I added it for my own use; so didn't mind too much about 
weird output.  If I resent it would be to drop my modifications to the 
message (it's redundant anyway - surely you know what you specified on the 
command line?), so feel free to just remove that hunk.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help