On 22/07/25 11:44 am, Aditya Garg wrote: > > > > > On 22 July 2025 10:39:01 am IST, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Aditya Garg <gargaditya08@xxxxxxxx> writes: >> >>> Or maybe you mean, ONLY send via imap and don't use SMTP? Like >>> this users can use their email clients to send emails? >> >> Exactly. You sold this feature as "have send-email send the >> message, and keep an extra copy you sent in your Sent imap folder". >> >> I pointed out that "have send-email do everything it would normally >> do before it talks to MSA or talk SMTP to send messages out, and >> instead drive imap-send to store these messages in a folder like >> imap-send users have used the program so far---as the user will send >> the messages out of their draft folder as was traditionally done by >> any imap-send users, send-email will *not* send anything out itself" >> as a possible different way send-email may want to use imap-send. >> >> These are two very different use cases. We could organize things >> this way: >> >> A1. When imap-folder is specified, that IMAP folder will get an extra >> copy, in addition to what send-email sends out; >> >> A2. When yet another new option, --send-email-no-send, is >> specified, send-email would not send any messages out. Even >> when this option is in effect, if --imap-folder is specified, >> that IMAP folder will get an extra copy, in addition to what >> send-email would send out (which is nothing). >> >> Or alternatively, we can have two very different operation modes >> that both involve imap-send: >> >> B1. When --imap-sent-folder is specified, that IMAP folder will get >> an extra copy, in addition to what send-email sent out via its >> usual route (like by invoking MSA or talking SMTP) >> >> B2. When --imap-outgo-folder is specified, that IMAP folder will >> get the outgo copy, later to be sent by the user (just like a >> user of imap-send would usually use), and send-email would not >> send out anything by its usual route. >> >> I thought the latter would be easier to explain to end-users, which >> is why "sent" or "fcc" or something like that should be in the name >> of the option when operating in the mode the patch implements. >> >> This brings up a yet another possibility. Invoking imap-send can be >> a new third way send-email uses to send out the messages, in addition >> to existing (1) invoking a local "/usr/lib/sendmail" program, or (2) >> talking SMTP to smarthost. That would be very easy to explain the >> operating mode B2 to users of send-email or users of imap-send, but >> it would be a bit awkward to find where B1 conceptually fits. >> > > Honestly, B2 looks like a doable thing, but I don't think people would really want to use this mode. Considering the fact that using an MSA or SMTP is much better, and commonly used. Also, imap-send was definitely not in use, especially looking that the fact that it was broken for a very long time. > > I'll rename it to imap-sent-folder, but the name looks more like it is only for "Sent" folder, and no other folder can be used. For example I like to keep a copy of the emails I send to git mailing list in a seperate 'git' folder in my mailbox. I can set the folder name as git, and thus have a copy saved there. What do you think about that? Also, as far as B2 is concerned, users can already do something like: git format-patch -2 HEAD --to=someone@xxxxxxxxxxx --stdout | git imap-send Which is more or less the same what git-send-email would do. The objective to add imap-send to send-email was not to add another feature for sending emails, but rather keep to copy of the sent emails at the desired correct place in their own mailbox.
