threads / discuss / 63496

Add git imap-get-recipients command

Subject: Add git imap-get-recipients command

## tl;dr

7 messages between May 21, 2025 and May 22, 2025.

replies: 6people: 3as markdown or json

Aditya Garg· May 21, 2025, 19:23 UTC · lore
Hi all

I was wondering if it would be acceptable for the maintainers to add a git imap-get-recipients command.

I currently am working on it, and it would be a perl script. It would do a very simple thing, take the message id as an input, and output the To: and Cc: recipients of that message ID.

This can be useful to be used alongwith git-send-email, when you send a v2 and you don't have to type all the sender mails again.

I got inspired to make this when I saw that replying to a v1 in a GUI client was so easy since all the recipients got filled automatically.

I currently am using a basic version of this with the --to-cmd command of git-send-email, but can polish it for git.

Junio C Hamano· May 21, 2025, 19:52 UTC · re: Aditya Garg · lore

Re: Add git imap-get-recipients command

Aditya Garg <gargaditya08@live.com> writes:
Show 5 quoted lines
> I was wondering if it would be acceptable for the maintainers to add a git imap-get-recipients
> command.
>
> I currently am working on it, and it would be a perl script. It would do a very simple thing,
> take the message id as an input, and output the To: and Cc: recipients of that message ID.

If you are selling this tool, you should clarify what the sources are for the information. There has to be a database of some sort that you can query with a message-ID and get addresses in that message. What are you using as that database (e.g., your personal mailbox? lore archive? an imap mailbox at your provider?) and how extensive and configurable is the data source? What data are you picking up from that database to come up with To/Cc addresses?

> This can be useful to be used alongwith git-send-email, when you send a v2 and you don't have to
> type all the sender mails again.

FWIW, if you're only duplicating the To/Cc list of the previous round, then I do not need it, and I do not want to see anybody, including you, to be using it. To come up with a list of To/Cc addresses to use in v2, you should start from those who commented on v1, in addition to To/Cc used in v1, and then whittle it down.

Again, the description of the "tool" in the first paragraph was so sketchy that I cannot tell where you are gathering the To/Cc addresses from or if the tool is using only the named message, or considers messages sent as response to that named message, so it is impossible to give a meaningful response. We cannot tell if the tool will be useful with given information.

A more generic version of the response follows to outline the general principle for those who are watching from sidelines.

---------------------------------------------------------------- [make us come to you, begging]

I've seen from time to time people ask "I am thinking of doing this; will a patch be accepted? If so, I'll work on it." before showing any work, and my response always has been:

 (1) We don't know how useful and interesting your contribution would
     be for our audience, until we see it; and
 (2) If you truly believe in your work (find it useful, find writing
     it fun, etc.), that would be incentive enough for you to work
     on it, whether or not the result will land in my tree.  You
     should instead aim for something so brilliant that we would
     come to you begging for your permission to include it in our
     project.
Junio C Hamano· May 22, 2025, 01:52 UTC · re: Junio C Hamano · lore

Re: Add git imap-get-recipients command

Junio C Hamano <gitster@pobox.com> writes:
Show 6 quoted lines
> Again, the description of the "tool" in the first paragraph was so
> sketchy that I cannot tell where you are gathering the To/Cc
> addresses from or if the tool is using only the named message, or
> considers messages sent as response to that named message, so it is
> impossible to give a meaningful response.  We cannot tell if the
> tool will be useful with given information.
I almost forgot to mention a few more things:
 - Perl dependency is something we seem to be avoiding these days.
 - Adding new things to contrib/ is also something we seem to be
   avoiding.
 - If it is only to help people to contribute to this project, I am
   not sure where in the hierarchy in my tree the tool should go.
   If it is to help people to contribute to any Git managed project,
   then it can be thrown into the same category as git-send-email,
   though.
 - Doesn't contributor side of b4 [*] do more or less what you want?
   If you find it lacking, it still may be a better idea to extend
   it instead of starting from scratch.
[Reference]
 * https://b4.docs.kernel.org/en/latest/contributor/overview.html
   Admittedly I do not use the contributor side of the tool,
   although I often use it for maintainer's tasks.  b4 knows the
   threading, what set of messages in the thread represents the
   latest iteration, etc., so it should already know enough to find
   out things like "who reviewed the previous round" that would help
   solving your "whom should I Cc this new iteration of patches?"
   problem.
Aditya Garg· May 22, 2025, 03:20 UTC · re: Junio C Hamano · lore

Re: Add git imap-get-recipients command

Show 17 quoted lines
> On 22 May 2025, at 1:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Aditya Garg <gargaditya08@live.com> writes:
> 
>> I was wondering if it would be acceptable for the maintainers to add a git imap-get-recipients
>> command.
>> 
>> I currently am working on it, and it would be a perl script. It would do a very simple thing,
>> take the message id as an input, and output the To: and Cc: recipients of that message ID.
> 
> If you are selling this tool, you should clarify what the sources
> are for the information.  There has to be a database of some sort
> that you can query with a message-ID and get addresses in that
> message.  What are you using as that database (e.g., your personal
> mailbox?  lore archive?  an imap mailbox at your provider?) and how
> extensive and configurable is the data source?  What data are you
> picking up from that database to come up with To/Cc addresses?

My plan was to select the Mailbox specified by the user and use the IMAP commands to search by message id

Show 9 quoted lines
> 
>> This can be useful to be used alongwith git-send-email, when you send a v2 and you don't have to
>> type all the sender mails again.
> 
> FWIW, if you're only duplicating the To/Cc list of the previous
> round, then I do not need it, and I do not want to see anybody,
> including you, to be using it.  To come up with a list of To/Cc
> addresses to use in v2, you should start from those who commented on
> v1, in addition to To/Cc used in v1, and then whittle it down.
Fair
Show 13 quoted lines
> 
> Again, the description of the "tool" in the first paragraph was so
> sketchy that I cannot tell where you are gathering the To/Cc
> addresses from or if the tool is using only the named message, or
> considers messages sent as response to that named message, so it is
> impossible to give a meaningful response.  We cannot tell if the
> tool will be useful with given information.
> 
> A more generic version of the response follows to outline the
> general principle for those who are watching from sidelines.
> 
> ----------------------------------------------------------------
> [make us come to you, begging]

No intentions to make come to me begging :(. But I do get the point. It's best to keep it to myself.

Show 15 quoted lines
> 
> I've seen from time to time people ask "I am thinking of doing this;
> will a patch be accepted?  If so, I'll work on it." before showing
> any work, and my response always has been:
> 
> (1) We don't know how useful and interesting your contribution would
>     be for our audience, until we see it; and
> 
> (2) If you truly believe in your work (find it useful, find writing
>     it fun, etc.), that would be incentive enough for you to work
>     on it, whether or not the result will land in my tree.  You
>     should instead aim for something so brilliant that we would
>     come to you begging for your permission to include it in our
>     project.
>
Emily Shaffer· May 22, 2025, 17:54 UTC · re: Aditya Garg · lore

Re: Add git imap-get-recipients command

On Wed, May 21, 2025 at 8:21 PM Aditya Garg <gargaditya08@live.com> wrote:
Show 50 quoted lines
>
>
>
> > On 22 May 2025, at 1:22 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Aditya Garg <gargaditya08@live.com> writes:
> >
> >> I was wondering if it would be acceptable for the maintainers to add a git imap-get-recipients
> >> command.
> >>
> >> I currently am working on it, and it would be a perl script. It would do a very simple thing,
> >> take the message id as an input, and output the To: and Cc: recipients of that message ID.
> >
> > If you are selling this tool, you should clarify what the sources
> > are for the information.  There has to be a database of some sort
> > that you can query with a message-ID and get addresses in that
> > message.  What are you using as that database (e.g., your personal
> > mailbox?  lore archive?  an imap mailbox at your provider?) and how
> > extensive and configurable is the data source?  What data are you
> > picking up from that database to come up with To/Cc addresses?
>
> My plan was to select the Mailbox specified by the user and use the IMAP
> commands to search by message id
> >
> >> This can be useful to be used alongwith git-send-email, when you send a v2 and you don't have to
> >> type all the sender mails again.
> >
> > FWIW, if you're only duplicating the To/Cc list of the previous
> > round, then I do not need it, and I do not want to see anybody,
> > including you, to be using it.  To come up with a list of To/Cc
> > addresses to use in v2, you should start from those who commented on
> > v1, in addition to To/Cc used in v1, and then whittle it down.
>
> Fair
> >
> > Again, the description of the "tool" in the first paragraph was so
> > sketchy that I cannot tell where you are gathering the To/Cc
> > addresses from or if the tool is using only the named message, or
> > considers messages sent as response to that named message, so it is
> > impossible to give a meaningful response.  We cannot tell if the
> > tool will be useful with given information.
> >
> > A more generic version of the response follows to outline the
> > general principle for those who are watching from sidelines.
> >
> > ----------------------------------------------------------------
> > [make us come to you, begging]
>
> No intentions to make come to me begging :(. But I do get the point.
> It's best to keep it to myself.

I actually don't think this is the point Junio was trying to make - rather that you should not need to feel like you have to ask for our permission to write this tool which can also stand alone and improve your own workflow. Rather, if you do write it and you find it useful, it'd be cool to see it sent to the mailing list alongside a cover letter like "would anybody else find value in this? It improved my workflow because <measurements/reasons>".

Definitely I don't believe Junio's point was "don't send us this patch, I don't care" - but rather "how do we know we care until we see how you've implemented it". (One reinforcement here is his question about where the Cc list is being queried from; local mbox vs. b4 vs. using a direct clone from lore.kernel.org would definitely change who this workflow will work well for.)

 - Emily
Show 15 quoted lines
> >
> > I've seen from time to time people ask "I am thinking of doing this;
> > will a patch be accepted?  If so, I'll work on it." before showing
> > any work, and my response always has been:
> >
> > (1) We don't know how useful and interesting your contribution would
> >     be for our audience, until we see it; and
> >
> > (2) If you truly believe in your work (find it useful, find writing
> >     it fun, etc.), that would be incentive enough for you to work
> >     on it, whether or not the result will land in my tree.  You
> >     should instead aim for something so brilliant that we would
> >     come to you begging for your permission to include it in our
> >     project.
> >
Aditya Garg· May 22, 2025, 17:59 UTC · re: Emily Shaffer · lore

Re: Add git imap-get-recipients command

Show 14 quoted lines
> I actually don't think this is the point Junio was trying to make -
> rather that you should not need to feel like you have to ask for our
> permission to write this tool which can also stand alone and improve
> your own workflow. Rather, if you do write it and you find it useful,
> it'd be cool to see it sent to the mailing list alongside a cover
> letter like "would anybody else find value in this? It improved my
> workflow because <measurements/reasons>".
> 
> Definitely I don't believe Junio's point was "don't send us this
> patch, I don't care" - but rather "how do we know we care until we see
> how you've implemented it". (One reinforcement here is his question
> about where the Cc list is being queried from; local mbox vs. b4 vs.
> using a direct clone from lore.kernel.org would definitely change who
> this workflow will work well for.)

My interpretation for Junio's comments were the same as your's. No hard feelings here.

But, at the same time, Junio also said this:

"FWIW, if you're only duplicating the To/Cc list of the previous round, then I do not need it, and I do not want to see anybody, including you, to be using it. To come up with a list of To/Cc addresses to use in v2, you should start from those who commented on v1, in addition to To/Cc used in v1, and then whittle it down."

Which is exactly what I was doing here :). And now that I think about it, it does make sense.

Junio C Hamano· May 22, 2025, 18:55 UTC · re: Emily Shaffer · lore

Re: Add git imap-get-recipients command

Emily Shaffer <nasamuffin@google.com> writes:
> Definitely I don't believe Junio's point was "don't send us this
> patch, I don't care" - but rather "how do we know we care until we see
> how you've implemented it".
Thanks for clarification.

Even without an implementation, a clear description of design (no, a design document on large swath of paper is often not what you want to come up with, as there clearly is a chicken-and-egg problem to convince others that the design is worth taking a look) would help.

← back to recent threads