git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: storing cover letter of a patch series?

From
MTMichael S. Tsirkin <mst@redhat.com>
Date
Aug 4, 2016, 23:43 UTC
Message-ID
<20160805024032-mutt-send-email-mst@kernel.org>
In-Reply-To
<CA+P7+xq2H-ZRix_71bQdswuEm++64ZA8FmK7J+1jhUhFeCZbgg@mail.gmail.com>
On Thu, Sep 10, 2015 at 02:03:48PM -0700, Jacob Keller wrote:
Show 44 quoted lines
> On Thu, Sep 10, 2015 at 1:09 PM, Philip Oakley <philipoakley@iee.org> wrote:
> > From: "Jacob Keller" <jacob.keller@gmail.com>
> >>
> >> On Thu, Sep 10, 2015 at 11:44 AM, Junio C Hamano <gitster@pobox.com>
> >> wrote:
> >>>
> >>> Jacob Keller <jacob.keller@gmail.com> writes:
> >>>
> >>>> I hadn't thought of separating the cover letter from git-send-email.
> >>>> That would be suitable for me.
> >>>
> >>>
> >>> Yeah, I said this number of times over time, and I said it once
> >>> recently in another thread, but I think it was a mistake to allow
> >>> git-send-email to drive format-patch.  It may appear that it will
> >>> make things convenient in the perfect world where no user makes
> >>> mistakes, but people are not perfect in real life.  Expecting them
> >>> to be is being naive.
> >>>
> >>
> >> Yep. I didn't even know cover-letter was an option of format-patch
> >> only thought it was in send-email.
> >>
> > Actually, the one feature I'd like (I think) is to be able to join together
> > the empty commit mechanism and the cover letter mechanism within format
> > patch so that:
> >
> > * the empty commit message would detected and automatically become the [0/N]
> > in the patch series (without need to say --cover-letter)
> >
> > * the cover letter would still have some 'template' markings to say "***
> > insert what's changed here***" or smilar (with option to exclude them).
> >
> > That way, when starting a series / branch, the first item would be to add
> > the explanatory 'empty commit' that states the requirements of what one
> > hopes to achieve (a key cover letter content), which is then followed by
> > commits that move toward that goal.
> >
> > The series can then be rebased as the user develops the code, and that cover
> > note can be edited as required during the rebase.
> >
> > When it comes time to show it to the list, the format patch will *know* from
> > the empty commit that it is the [0/N] cover letter and (perhaps -option) add
> > the appropriate markers ready for editing.

And perhaps git am could learn an option to apply 0/N as a cover commit.

Show 17 quoted lines
> > The user edits the cover letter with the extra 'what's changed' / interdiff
> > / whatever, and sends. sendmail barfs if the user hasn't edited the markers.
> >
> > This could also work with the sendmail patch formating (though I've never
> > used that workflow) as now the cover letter becomes automatic for the
> > upstream.
> >
> > Philip
> 
> If there was a way to store this empty commit message tagged as "cover
> letter" that could work well, though generally I prefer the
> non-fast-forward merges as this shows you where the series ended *and*
> began. It's somewhat confusing to newer users.. and this doesn't get
> rebased very well either.
> 
> Some way to indicate a particular "empty" commit is actually a cover
> letter seems easy enough. This seems like the way that I was thinking.

Start the subject with "cover! "? I have a patch that teaches git-rebase to keep empty commits where the subject has a given prefix, that might be helpful there.

Show 15 quoted lines
> Using "edit description" of git-branch seems also to be pretty
> effective for this, even if it doesn't get shared across remotes. (not
> really a necessary feature for what I do).
> 
> But having some way to indicate "cover letter" which gets used as the
> beginning of a log message when doing a particular "merge
> --tip-as-cover" or something like Junio suggested above seems like the
> nicest approach.
> 
> Regards,
> Jake
> --
> 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
Previous: Jacob KellerNext: Johannes Schindelin
Message 22 of 57 in “storing cover letter of a patch series?”
  1. Jacob KellerSep 10, 2015
  2. Junio C HamanoSep 10, 2015
  3. Martin FickSep 10, 2015
  4. Jacob KellerSep 10, 2015
  5. Junio C HamanoSep 10, 2015
  6. Junio C HamanoSep 11, 2015
  7. Michael S. TsirkinAug 4, 2016
  8. Junio C HamanoAug 5, 2016
  9. Martin FickAug 5, 2016
  10. Junio C HamanoAug 5, 2016
  11. Junio C HamanoAug 6, 2016
  12. Michael S. TsirkinAug 7, 2016
  13. John KeepingAug 7, 2016
  14. Duy NguyenAug 7, 2016
  15. Junio C HamanoAug 8, 2016
  16. Michael J GruberAug 9, 2016
  17. Jacob KellerSep 10, 2015
  18. Junio C HamanoSep 10, 2015
  19. Jacob KellerSep 10, 2015
  20. Philip OakleySep 10, 2015
  21. Jacob KellerSep 10, 2015
  22. Michael S. TsirkinAug 4, 2016
  23. Johannes SchindelinSep 10, 2015
  24. Jacob KellerSep 10, 2015
  25. Johannes SchindelinSep 10, 2015
  26. Philip OakleySep 10, 2015
  27. doc: show usage of branch descriptionPhilip Oakley, Sep 12, 2015
  28. Jacob KellerSep 12, 2015
  29. Philip OakleySep 14, 2015
  30. Philip OakleySep 14, 2015
  31. Junio C HamanoSep 14, 2015
  32. Philip OakleySep 15, 2015
  33. Philip OakleySep 15, 2015
  34. doc: show usage of branch descriptionPhilip Oakley, Sep 14, 2015
  35. Chris PackhamSep 11, 2015
  36. Simon GlassSep 18, 2015
  37. Stefan BellerAug 8, 2016
  38. Junio C HamanoAug 8, 2016
  39. Duy NguyenAug 13, 2016
  40. Jacob KellerAug 14, 2016
  41. Stefan BellerAug 15, 2016
  42. Jacob KellerAug 15, 2016
  43. Stefan BellerAug 15, 2016
  44. Jacob KellerAug 15, 2016
  45. Duy NguyenAug 15, 2016
  46. Philip OakleyAug 15, 2016
  47. Duy NguyenAug 15, 2016
  48. John KeepingAug 15, 2016
  49. Jacob KellerAug 15, 2016
  50. Junio C HamanoAug 15, 2016
  51. Jacob KellerAug 15, 2016
  52. Philip OakleyAug 15, 2016
  53. Duy NguyenAug 16, 2016
  54. Jacob KellerAug 16, 2016
  55. Duy NguyenAug 16, 2016
  56. Jacob KellerAug 16, 2016
  57. Philip OakleyAug 16, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.