Including branch info in git format-patch

Including branch info in git format-patch

[Mukund Sivaraman]

Hi all

We have two public branches on the tinyproxy project[1]: master and 1.6.
We send patches to the mailing list to get them reviewed before they are
applied and pushed to the public repo.

When i use "git format-patch", it doesn't seem to include the branch (or
remote) name in the email it creates. So a reader of this mail may not
know what branch to apply it on to test it. Aside from adding in branch
information manually in the body of the message, is there any other
existing way to get git format-patch to include it?

Apologies in advance if this is a stupid question.

		Mukund

Refs:
 1. http://git.banu.com/?p=tinyproxy;a=summary

Re: Including branch info in git format-patch

[Jeff King]

On Thu, Jun 19, 2008 at 09:12:52PM +0530, Mukund Sivaraman wrote:

> When i use "git format-patch", it doesn't seem to include the branch (or
> remote) name in the email it creates. So a reader of this mail may not
> know what branch to apply it on to test it. Aside from adding in branch
> information manually in the body of the message, is there any other
> existing way to get git format-patch to include it?

No, there isn't a way to do it automatically. On this mailing list,
patches are assumed to be on top of "master" unless explicitly indicated
otherwise. And we usually just mention it manually.

You could potentially add a config option to put the branch name inside
the '[PATCH]' text. This text is generally stripped away before
applying, so it would still free up the receiver to apply on whatever
branch they wanted. I don't think it would make sense for git
development, since we typically use topic branches, so keeping it
configurable would make sense.

On the receiving end, the applying party could set up their MUA to split
patches based on the subject, and then apply them as appropriate (this
very much depends on their workflow for applying patches). You could
probably even do a pre-applypatch hook as a safety valve to make sure
things were being applied in the right place.

-Peff

Re: Including branch info in git format-patch

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> You could potentially add a config option to put the branch name inside
> the '[PATCH]' text. This text is generally stripped away before
> applying, so it would still free up the receiver to apply on whatever
> branch they wanted. I don't think it would make sense for git
> development, since we typically use topic branches, so keeping it
> configurable would make sense.

People would work on individual patches on topic branches that are named
differently from the branch on the other end anyway (the branch that
corresonds to the other end will be used for local integration testing in
such a setup), so I do not see much point in stating which local branch
happened to have been checked out when the patch was generated, in the
output.

Also, in git, there is no independent "branch history", so anybody who
says "this patch was taken from this branch" is either speaking very
loosely, or does not understand git's branching model at all, or bit of
both.

If you have a history of this shape:

                    (other cruft)
                          \
                   ----o---o next
                      /
         o---o---o---o master
        /       /
    ---o---o---A

which "branch label" would you give to the format-patch output that shows
commit A?  It may apply to both master and next, and it is really up to
the project's convention what to do with it.  The side branch the patch
was developed on may be named "quick-hack", which would not have any
relevance to the final location of where that patch wants to be in.

Re: Including branch info in git format-patch

[Jeff King]

On Thu, Jun 19, 2008 at 01:54:15PM -0700, Junio C Hamano wrote:

> > You could potentially add a config option to put the branch name inside
> > the '[PATCH]' text. This text is generally stripped away before
> > applying, so it would still free up the receiver to apply on whatever
> > branch they wanted. I don't think it would make sense for git
> > development, since we typically use topic branches, so keeping it
> > configurable would make sense.
> 
> People would work on individual patches on topic branches that are named
> differently from the branch on the other end anyway (the branch that
> corresonds to the other end will be used for local integration testing in
> such a setup), so I do not see much point in stating which local branch
> happened to have been checked out when the patch was generated, in the
> output.

I think that is totally dependent on the workflow, which is what I was
trying to say above. It really depends on how the patch-submitter
organizes his branches.

> the project's convention what to do with it.  The side branch the patch
> was developed on may be named "quick-hack", which would not have any
> relevance to the final location of where that patch wants to be in.

I suspect you would do better to look at branch.quick-hack.merge, so
that you say "this was based on upstream's X", not "this is my
quick-hack".

But there are so many ways this could go wrong, since the patches you're
formatting might not even have anything to do with the branch you're on.

-Peff

Re: Including branch info in git format-patch

[Jeff King]

On Thu, Jun 19, 2008 at 05:06:17PM -0400, Jeff King wrote:

> > the project's convention what to do with it.  The side branch the patch
> > was developed on may be named "quick-hack", which would not have any
> > relevance to the final location of where that patch wants to be in.
> 
> I suspect you would do better to look at branch.quick-hack.merge, so
> that you say "this was based on upstream's X", not "this is my
> quick-hack".
> 
> But there are so many ways this could go wrong, since the patches you're
> formatting might not even have anything to do with the branch you're on.

Side note: if you have a particular workflow, it might make sense,
rather than using format-patch directly, to codify that workflow in
another script which says "ok, this is how I grab a branch and send it
upstream". And in that case, you could look up "here's where I branched
from" and feed it into the patch via format-patch's --subject-prefix
option.

-Peff

Re: Including branch info in git format-patch

[Sverre Rabbelier]

On Thu, Jun 19, 2008 at 10:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> You could potentially add a config option to put the branch name inside
>> the '[PATCH]' text. This text is generally stripped away before
>> applying, so it would still free up the receiver to apply on whatever
>> branch they wanted. I don't think it would make sense for git
>> development, since we typically use topic branches, so keeping it
>> configurable would make sense.
>
> People would work on individual patches on topic branches that are named
> differently from the branch on the other end anyway (the branch that
> corresonds to the other end will be used for local integration testing in
> such a setup), so I do not see much point in stating which local branch
> happened to have been checked out when the patch was generated, in the
> output.

I think what Mukund is asking for is a way to specify what upstream
branch the commit should be applied to. This would be a feature to
help the person who is going to do the applying, so it is ok if the
person formatting the patch has to do a little work for that (e.g.,
specify which upstream branch to format-patch as a cmdline option)

> If you have a history of this shape:
<snip>
> which "branch label" would you give to the format-patch output that shows
> commit A?  It may apply to both master and next, and it is really up to
> the project's convention what to do with it.  The side branch the patch
> was developed on may be named "quick-hack", which would not have any
> relevance to the final location of where that patch wants to be in.

You would give it the label of the branch you want it applied to!

-- 
Cheers,

Sverre Rabbelier

Re: Including branch info in git format-patch

[Mukund Sivaraman]

On Thu, Jun 19, 2008 at 01:54:15PM -0700, Junio C Hamano wrote:
> If you have a history of this shape:
> 
>                     (other cruft)
>                           \
>                    ----o---o next
>                       /
>          o---o---o---o master
>         /       /
>     ---o---o---A
> 
> which "branch label" would you give to the format-patch output that shows
> commit A?  It may apply to both master and next, and it is really up to
> the project's convention what to do with it.  The side branch the patch
> was developed on may be named "quick-hack", which would not have any
> relevance to the final location of where that patch wants to be in.

I follow what you are saying. In our workflow case, pointing out the
remote (public) branch name should be sufficient (as this's the public
shared branch among us, and all patchsets shared with others are against
the public branches). Perhaps I can add it to the [PATCH] text in the
subject line as Jeff suggests.

My problem is that I can't send a patch out to the list for other
developers to try, without some annotation for them, of which branch to
try it on.

		Mukund

Re: Including branch info in git format-patch

[Junio C Hamano]

Mukund Sivaraman <muks@banu.com> writes:

> My problem is that I can't send a patch out to the list for other
> developers to try, without some annotation for them, of which branch to
> try it on.

So what's wrong telling that when you send out the patch, between the time
you run format-patch and send-email?

Re: Including branch info in git format-patch

[Mukund Sivaraman]

On Thu, Jun 19, 2008 at 02:41:54PM -0700, Junio C Hamano wrote:
> > My problem is that I can't send a patch out to the list for other
> > developers to try, without some annotation for them, of which branch to
> > try it on.
> 
> So what's wrong telling that when you send out the patch, between the time
> you run format-patch and send-email?
> 

I had asked if there was some way the remote branch name could
automatically be inserted by git format-patch, instead of manually adding
it in the patch message or in a cover letter. What Jeff suggested seems
good to me (of using --subject-prefix) as that is removed automatically
when the patch is applied by git am.

		Mukund