Re: Add git imap-get-recipients command

From: Aditya Garg <gargaditya08@live.com>
Date: May 22, 2025, 17:59 UTC
Message-ID: <PN3PR01MB9597940EFDC160CF7DB2F53AB899A@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <CAJoAoZm_fsfhq2gD4JVCihf5do-+CurFRBfw8PX8-0QbSKk-VA@mail.gmail.com>

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.