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

Re: [RFC v2] git-multimail: a replacement for post-receive-email

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Feb 24, 2013, 05:53 UTC
Message-ID
<5129AAEB.5080007@alum.mit.edu>
In-Reply-To
<vpqfw0rb25c.fsf@grenoble-inp.fr>
On 02/20/2013 01:28 PM, Matthieu Moy wrote:
Show 23 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> A while ago, I submitted an RFC for adding a new email notification
>> script to "contrib" [...]
> 
> We've discussed offline with Michael, a few patches have been merged,
> and there are still a few pending pull requests. I liked the script
> already, but it's getting even cooler ;-).
> 
> A few more random thoughts (not on my personal todo-list):
> 
> [...]
> 
> * Perhaps we should allow a per-branch configuration, like
> 
>   [multimailhook]
> 	mailingList = some@list.com
>   [multimailhook "refs/heads/my-branch"]
>         mailingList = some-other@list.com
>         <whateverOtherConfig> = <whateverOtherValue>
> 
>   Branch specific would override value for Config.get(), and
>   Config.get_all() should probably list both the branch-specific and the
>   other keys.

I wonder whether it would be to far off the beaten path to allow glob patterns in the branch specification; e.g.,

   [multimailhook "refs/heads/release-*"]
         mailingList = qa@example.com

For the case of multiple glob patterns matching a branch name, there would probably have to be a notion of "best match", but that doesn't seem too difficult. The matching would have to take place when looking up individual options to avoid having to replicate the full configuration for each pattern.

This feature could also be used to get the functionality of your proposal for skipRefs and onlyRefs [1] in a more general way:

   [multimailhook]
         mailingList = some@example.com
   [multimailhook "refs/heads/user/$USER/*"]
         mailingList = ""
Michael

[1] Proposed feature to allow certain references to be ignored for the purpose of notification emails; see

    https://github.com/mhagger/git-multimail/pull/15
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Michael HaggertyNext: Matthieu Moy
Message 15 of 17 in “[RFC v2] git-multimail: a replacement for post-receive-email”
  1. Michael HaggertyJan 27, 2013
  2. Ævar Arnfjörð BjarmasonJan 29, 2013
  3. Chris HiestandJan 30, 2013
  4. Matthieu MoyFeb 13, 2013
  5. Andy ParkinsFeb 13, 2013
  6. Matthieu MoyFeb 13, 2013
  7. Michael HaggertyFeb 13, 2013
  8. Matthieu MoyFeb 14, 2013
  9. Michael HaggertyFeb 15, 2013
  10. Matthieu MoyFeb 20, 2013
  11. Michael HaggertyFeb 24, 2013
  12. Matthieu MoyFeb 25, 2013
  13. Michael HaggertyFeb 25, 2013
  14. Michael HaggertyMar 9, 2013
  15. Michael HaggertyFeb 24, 2013
  16. Matthieu MoyFeb 25, 2013
  17. Matthieu MoyMar 4, 2013

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.