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

Re: [RFC 1/3] mailinfo: extract patch series id

From
Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.de>
Date
Nov 14, 2017, 09:10 UTC
Message-ID
<e49e107d-b211-f544-9512-b83eab9dd82a@suse.de>
In-Reply-To
<xmqqfu9h4div.fsf@gitster.mtv.corp.google.com>
Le 14/11/2017 à 06:47, Junio C Hamano a écrit :
Show 21 quoted lines
> Nicolas Morey-Chaisemartin <NMoreyChaisemartin@suse.de> writes:
>
>> Extract the patch ID and series length from the [PATCH N/M]
>>  prefix in the mail header
>>
>> Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
>> ---
>>  mailinfo.c | 35 +++++++++++++++++++++++++++++++++++
>>  mailinfo.h |  2 ++
>>  2 files changed, 37 insertions(+)
> As JTan already mentioned, relying on a substring "PATCH" may not be
> very reliable, and trying to locate "%d/%d]" feels like a better
> approach.
>
> cleanup_subject() is called only when keep_subject is false, so this
> code will not trigger in that case at all.  Is this intended?
>
> I would have expected that a new helper function would be written,
> without changing existing helpers like cleanup_subject(), and that
> new helper gets called by handle_info() after output_header_lines()
> helper is called for the "Subject".
Isn't that too late ?
If keep subject is not set, will cleanup_subject not drop all those info from the strbuf  ?
But yes it is not in the right function now.
But I would call the function before
            if (!mi->keep_subject) {
Show 14 quoted lines
>
> Whenever mailinfo learns to glean a new useful piece of information,
> it should be made available to scripts that run "git mailinfo", too.
> Perhaps show something like
>
> 	PatchNumber: 1
> 	TotalPatches: 3
>
> at the end of handle_info() to mi->output?  I do not think existing
> tools mind too much, even if we added a for-debug output e.g.
>
> 	RawSubject: [RFC 1/3] mailinfo: extract patch series id
>
> to the output.
Will do.
Previous: Junio C HamanoNext: Nicolas Morey-Chaisemartin
Message 13 of 25 in “[RFC] cover-at-tip”
  1. Nicolas Morey-ChaisemartinNov 10, 2017
  2. Nicolas Morey-ChaisemartinNov 10, 2017
  3. Junio C HamanoNov 10, 2017
  4. Nicolas Morey-ChaisemartinNov 13, 2017
  5. Junio C HamanoNov 13, 2017
  6. Junio C HamanoNov 13, 2017
  7. Nicolas Morey-ChaisemartinNov 13, 2017
  8. 0/3 Add support for --cover-at-tipNicolas Morey-Chaisemartin, Nov 13, 2017
  9. Jonathan TanNov 13, 2017
  10. Nicolas Morey-ChaisemartinNov 13, 2017
  11. 1/3 mailinfo: extract patch series idNicolas Morey-Chaisemartin, Nov 13, 2017
  12. Junio C HamanoNov 14, 2017
  13. Nicolas Morey-ChaisemartinNov 14, 2017
  14. 2/3 am: semi working --cover-at-tipNicolas Morey-Chaisemartin, Nov 13, 2017
  15. Junio C HamanoNov 14, 2017
  16. Nicolas Morey-ChaisemartinNov 14, 2017
  17. Nicolas Morey-ChaisemartinNov 16, 2017
  18. Junio C HamanoNov 17, 2017
  19. 3/3 log: add an option to generate cover letter from a branch tipNicolas Morey-Chaisemartin, Nov 13, 2017
  20. Junio C HamanoNov 14, 2017
  21. Nicolas Morey-ChaisemartinNov 14, 2017
  22. Junio C HamanoNov 14, 2017
  23. Nicolas Morey-ChaisemartinNov 14, 2017
  24. Junio C HamanoNov 14, 2017
  25. Jonathan TanNov 10, 2017

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.