[RFC] git-format-patch options

[RFC] git-format-patch options

[Luben Tuikov]

It is often the case that "since <mine> head forked from
<his> head" (quoting the manual page of git-format-patch),
for various projects, some patches have been accepted and
some have not.

I was wondering about the value of

  git-format-patch <commit-ish>

to output/prepare a diff patch between the indicated commit
and its parent.  As opposed to the current behaviour giving
all changes between the indicated commit and HEAD.

So in effect the form above would become the trivial:

  git-format-patch <commit-ish>..HEAD

and

  git-format-patch <commit-ish>

would give the diff patch between the indicated commit and
its parent.

?

    Luben

Re: [RFC] git-format-patch options

[Andreas Ericsson]

Luben Tuikov wrote:
> It is often the case that "since <mine> head forked from
> <his> head" (quoting the manual page of git-format-patch),
> for various projects, some patches have been accepted and
> some have not.
> 
> I was wondering about the value of
> 
>   git-format-patch <commit-ish>
> 
> to output/prepare a diff patch between the indicated commit
> and its parent.  As opposed to the current behaviour giving
> all changes between the indicated commit and HEAD.
> 
> So in effect the form above would become the trivial:
> 
>   git-format-patch <commit-ish>..HEAD
> 
> and
> 
>   git-format-patch <commit-ish>
> 
> would give the diff patch between the indicated commit and
> its parent.
> 

Please don't. git-format-patch is generally used to send in a series of 
patches ranging back from HEAD, so this would mean less userfriendliness 
in the most usual case.

Here's the "sed -n 90,100p" commentary from git-format-patch:
----%<-----%<----
# Backward compatible argument parsing hack.
#
# Historically, we supported:
# 1. "rev1"     is equivalent to "rev1..HEAD"
# 2. "rev1..rev2"
# 3. "rev1" "rev2   is equivalent to "rev1..rev2"
#
# We want to take a sequence of "rev1..rev2" in general.
# Also, "rev1.." should mean "rev1..HEAD"; git-diff users are
# familiar with that syntax.
----%<-----%<----

Perhaps the man-page needs to be updated with this info.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [RFC] git-format-patch options

[Luben Tuikov]

--- Andreas Ericsson <ae@op5.se> wrote:

> 
> Please don't. git-format-patch is generally used to send 

Ok, so then when I want to extract a single commit into a patch in a patch format, I loosely do
(scripted):

  git-rev-list --pretty=raw --max-count=1 <commit-ish>

Then I record the parent <parent> of the commit-ish and do:

  git-format-patch [output options] <parent>..<commit-ish>

Which gives me the commit with id <commit-ish> as a
formatted patch.

Is there an alernative to this, as opposed to the two
step procedure above?

   Luben

Re: [RFC] git-format-patch options

[Andreas Ericsson]

Luben Tuikov wrote:
> --- Andreas Ericsson <ae@op5.se> wrote:
> 
> 
>>Please don't. git-format-patch is generally used to send 
> 
> 
> Ok, so then when I want to extract a single commit into a patch in a patch format, I loosely do
> (scripted):
> 
>   git-rev-list --pretty=raw --max-count=1 <commit-ish>
> 
> Then I record the parent <parent> of the commit-ish and do:
> 
>   git-format-patch [output options] <parent>..<commit-ish>
> 
> Which gives me the commit with id <commit-ish> as a
> formatted patch.
> 
> Is there an alernative to this, as opposed to the two
> step procedure above?
> 

Here's how to automate it.

git format-patch $(git rev-list --max-count=2 <commit-ish> | tail -n 
1)..<commit-ish>

Either way, you need to know <commit-ish>, but this format should be 
fairly easy to add to git-format-patch. If you do, please let the user 
specify the --max-count (but default to 1) so it can be used to extract 
a series of patches rather than just one.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [RFC] git-format-patch options

[Luben Tuikov]

--- Andreas Ericsson <ae@op5.se> wrote:

> Here's how to automate it.
> 
> git format-patch $(git rev-list --max-count=2 <commit-ish> | tail -n 
> 1)..<commit-ish>

I've a similar script, called
"git-format-commit-patch <commit-ish>" which is slightly
more involved.

> Either way, you need to know <commit-ish>, but this format should be 
> fairly easy to add to git-format-patch. If you do, please

How about git-format-patch --commit <commit-ish>
to generate the formatted patch of only what _that_ commit
introduced? (i.e. <parent>..<commit-ish>)

Do people find this valuable to have?

    Luben
P.S. Since it is really trivial to write such a script
on top of git-rev-list and git-format-patch, it may be
easier to just leave things as they are.  It was just
something I needed, which I thought other people might
need too.

Re: [RFC] git-format-patch options

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

Luben Tuikov wrote:
> --- Andreas Ericsson <ae@op5.se> wrote:
> 
> 
>>Here's how to automate it.
>>
>>git format-patch $(git rev-list --max-count=2 <commit-ish> | tail -n 
>>1)..<commit-ish>
> 
> 
> I've a similar script, called
> "git-format-commit-patch <commit-ish>" which is slightly
> more involved.
> 
> 
>>Either way, you need to know <commit-ish>, but this format should be 
>>fairly easy to add to git-format-patch. If you do, please
> 
> 
> How about git-format-patch --commit <commit-ish>
> to generate the formatted patch of only what _that_ commit
> introduced? (i.e. <parent>..<commit-ish>)

Doesn't git-format-patch $commit^1..$commit do what you want?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [RFC] git-format-patch options

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> I was wondering about the value of
>
>   git-format-patch <commit-ish>
>
> to output/prepare a diff patch between the indicated commit
> and its parent.  As opposed to the current behaviour giving
> all changes between the indicated commit and HEAD.

Yes, that would be "git-format-patch $commit^1 $commit", but it
might deserve better shortcuts.

Later Andreas quoted the backward compatibility constraints:

> # Backward compatible argument parsing hack.
> #
> # Historically, we supported:
> # 1. "rev1"     is equivalent to "rev1..HEAD"
> # 2. "rev1..rev2"
> # 3. "rev1" "rev2   is equivalent to "rev1..rev2"
> #
> # We want to take a sequence of "rev1..rev2" in general.
> # Also, "rev1.." should mean "rev1..HEAD"; git-diff users are
> # familiar with that syntax.

The case statement that follows that comment is not quite right,
BTW.  "format-patch foo bar..baz" should mean sequence of "foo"
and then "bar..baz", but it incorrectly translates to a
malformed "foo..bar..baz".

Modulo that bug, what the current code does is to special case
one or two arguments case and rewrite them in that case
statement, and then iterate over the resulting "$@".  We barf if
each 'revpair' is not in rev1..rev2 format.

But it might make sense to (still keeping the above three
backward compatibility syntax exceptions) interpret "rev" to
mean "rev^1..rev", like this:

---

diff --git a/git-format-patch.sh b/git-format-patch.sh
index 7ee5d32..351790c 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -99,7 +99,7 @@ filelist=$tmp-files
 # Also, "rev1.." should mean "rev1..HEAD"; git-diff users are
 # familiar with that syntax.
 
-case "$#,$1" in
+case "$#,$1$2" in
 1,?*..?*)
 	# single "rev1..rev2"
 	;;
@@ -131,7 +131,8 @@ do
 		rev2=`expr "$revpair" : '.*\.\.\(.*\)'`
 		;;
 	*)
-		usage
+		rev1="$revpair^"
+		rev2="$revpair"
 		;;
 	esac
 	git-rev-parse --verify "$rev1^0" >/dev/null 2>&1 ||

Re: [RFC] git-format-patch options

[Luben Tuikov]

--- Ryan Anderson <ryan@michonline.com> wrote:

> Doesn't git-format-patch $commit^1..$commit do what you want?
> 

Yes, this is the one.  Thanks!

    Luben

Re: [RFC] git-format-patch options

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:

> 
> The case statement that follows that comment is not quite right,
> BTW.  "format-patch foo bar..baz" should mean sequence of "foo"
> and then "bar..baz", but it incorrectly translates to a
> malformed "foo..bar..baz".
> 
> Modulo that bug, what the current code does is to special case
> one or two arguments case and rewrite them in that case
> statement, and then iterate over the resulting "$@".  We barf if
> each 'revpair' is not in rev1..rev2 format.
> 
> But it might make sense to (still keeping the above three
> backward compatibility syntax exceptions) interpret "rev" to
> mean "rev^1..rev", like this:

Ok, I don't understand the patch below.  I tried
to get from "rev" to a "rev^1..rev" or the identical
"rev^1 rev", but could never do it with git-format-patch.
So for now I just use the "rev^1..rev".

BTW, here is the analogy:
  git-diff-tree --pretty=raw -p <commit-id>
does what I want, except that it is not in patch format
as expected.  So it is quite possible to just add a
command line parameter to git-diff-tree to indicate
"formatted patch output", and we're done.

    Luben

> 
> ---
> 
> diff --git a/git-format-patch.sh b/git-format-patch.sh
> index 7ee5d32..351790c 100755
> --- a/git-format-patch.sh
> +++ b/git-format-patch.sh
> @@ -99,7 +99,7 @@ filelist=$tmp-files
>  # Also, "rev1.." should mean "rev1..HEAD"; git-diff users are
>  # familiar with that syntax.
>  
> -case "$#,$1" in
> +case "$#,$1$2" in
>  1,?*..?*)
>  	# single "rev1..rev2"
>  	;;
> @@ -131,7 +131,8 @@ do
>  		rev2=`expr "$revpair" : '.*\.\.\(.*\)'`
>  		;;
>  	*)
> -		usage
> +		rev1="$revpair^"
> +		rev2="$revpair"
>  		;;
>  	esac
>  	git-rev-parse --verify "$rev1^0" >/dev/null 2>&1 ||
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>