[RFC] git-format-patch options

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

Luben Tuikov wrote:

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 <ae@op5.se> wrote:

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

Luben Tuikov wrote:

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 <ae@op5.se> wrote:

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

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.

Luben Tuikov wrote:

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

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

Yes, this is the one.  Thanks!

    Luben

Luben Tuikov <ltuikov@yahoo.com> writes:

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

Later Andreas quoted the backward compatibility constraints:

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:

---

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

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