git format-patch should honor notes

> So, what I'm missing is the ability for 'git send-email' (or more
> fundamentally, 'git format-patch') to be able to include contents of a
> particular (set of) notes reference in each patch file it generates,
> where the note falls in the informative portion of the email, and is
> intentionally omitted from the upstream commit when someone else runs
> 'git am' on my email.

> My workflow is that I post patch series for upstream review via 'git
> send-email'.  Often, that results in feedback that requires me to
> amend/rebase my series, and post a v2 or v3 of the series.  By adding
> 'git config notes.rewriteRef refs/notes/commits', I can add notes that
> will carry across my rebase, and remind me what I changed in v2 (for
> example, git notes add -m 'v2: fix foo, per mail xyz@example.com').
> This is handy for me, and I think it is also handy for reviewers -
> someone who took the time to read through v1 should know what I changed
> in response to their comments, and only have to focus in on commits with
> changes, rather than on the entire resent series.

> On Tue, Dec 07, 2010 at 02:53:09PM -0700, Eric Blake wrote:
> 
>> My workflow is that I post patch series for upstream review via 'git
>> send-email'.  Often, that results in feedback that requires me to
>> amend/rebase my series, and post a v2 or v3 of the series.  By adding
>> 'git config notes.rewriteRef refs/notes/commits', I can add notes that
>> will carry across my rebase, and remind me what I changed in v2 (for
>> example, git notes add -m 'v2: fix foo, per mail xyz@example.com').
>> This is handy for me, and I think it is also handy for reviewers -
>> someone who took the time to read through v1 should know what I changed
>> in response to their comments, and only have to focus in on commits with
>> changes, rather than on the entire resent series.
> 
> Yeah, that is a workflow that some others have mentioned using here,
> too. And I think there is general agreement that notes should go after
> the "---" in format-patch. We just need a working patch.
> 
> Thomas posted one in February:
> 
>   http://article.gmane.org/gmane.comp.version-control.git/140819
> 
> But there were some issues and it never got polished. Michael suggested
> that he does something similar here:
> 
>   http://article.gmane.org/gmane.comp.version-control.git/140819
> 
> but there was no indication on whether it happens manually or if he has
> a patch. I don't know if anything else has happened in that area. I'm
> sure if you feel like working on a patch it would be well received.
> 
> -Peff

> Also, in order to be really useful, I would need a place to store the
> cover letter also. I was experimenting a while back with a design for
> annotating branchnames which "basically" worked but haven't had time
> to really implement it. If I remember correctly, I had to set up some
> "bogus" refs to keep my notes from being garbage collected and was
> still figuring out the best place to put them. I'll dig it up when I
> have time to.

> On Wednesday 08 December 2010, Michael J Gruber wrote:
>> Also, in order to be really useful, I would need a place to store the
>> cover letter also. I was experimenting a while back with a design for
>> annotating branchnames which "basically" worked but haven't had time
>> to really implement it. If I remember correctly, I had to set up some
>> "bogus" refs to keep my notes from being garbage collected and was
>> still figuring out the best place to put them. I'll dig it up when I
>> have time to.
> 
> I believe the last time the issue of adding notes to branch names was 
> discussed, the consensus was that rather than using notes, they could 
> be stored using a custom entry in the config file, e.g.
> 
>   git config branch.mybranch.description "Description of mybranch"
> 
> I might have misremembered this, though.

> Johan Herland venit, vidit, dixit 08.12.2010 11:12:
> > On Wednesday 08 December 2010, Michael J Gruber wrote:
> >> Also, in order to be really useful, I would need a place to store
> >> the cover letter also. I was experimenting a while back with a
> >> design for annotating branchnames which "basically" worked but
> >> haven't had time to really implement it. If I remember correctly,
> >> I had to set up some "bogus" refs to keep my notes from being
> >> garbage collected and was still figuring out the best place to put
> >> them. I'll dig it up when I have time to.
> >
> > I believe the last time the issue of adding notes to branch names
> > was discussed, the consensus was that rather than using notes, they
> > could be stored using a custom entry in the config file, e.g.
> >
> >   git config branch.mybranch.description "Description of mybranch"
> >
> > I might have misremembered this, though.
>
> They certainly "could". The question whether they "should" depends on
> what they are used for:
>
> - config is neither versioned nor easily shareable; perfect for your
> own scratch notes to go away once work is done
>
> - notes are versioned and can be shared (I don't need to tell
> you...); perfect for longer term annotations you want to keep
>
> Note that "sharing" here includes also pushing to your backup repo
> and cloning around. I'd certainly put patch series cover letters in
> the second category.

> > My workflow is that I post patch series for upstream review via 'git
> > send-email'.  Often, that results in feedback that requires me to
> > amend/rebase my series, and post a v2 or v3 of the series.  By adding
> > 'git config notes.rewriteRef refs/notes/commits', I can add notes that
> > will carry across my rebase, and remind me what I changed in v2 (for
> > example, git notes add -m 'v2: fix foo, per mail xyz@example.com').
> 
> Yeah, that is a workflow that some others have mentioned using here,

> too. And I think there is general agreement that notes should go after
> the "---" in format-patch. We just need a working patch.
> 
> Thomas posted one in February:
> 
>   http://article.gmane.org/gmane.comp.version-control.git/140819
> 
> But there were some issues and it never got polished.