On Wed, Feb 08, 2023 at 02:06:55AM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
Side note: If somebody were proposing to add imap-send at all today,
I'd probably say "no, that should be a separate project, and you
should probably write it in some language that has a decent imap
library". It really has nothing at all to do with Git in terms of
implementation, and I suspect it's not super well maintained in
general. But perhaps it is too late for that.
I think it's a reasonable feature, but in hindsight our mistake was to
think that we should be perma-forking isync, which has since moved
on. I've used isync's "mbsync" extensively for IMAP in other contexts,
and it works well for that.
So if we were going back to the drawing board a "git-imap-sync" really
should just be something in our mail tooling that can produce a Maildir,
and if we wanted an IMAP helper it could invoke mbsync, offlineimap or
various other "maildir to IMAP" bidirectional syncing utilities to
"send" via IMAP.
So, just some hook support for format-patch with some documented
examples should do it, but I won't be working on that task...
Yes, I think format-patch plus a sync program would be good. I did
briefly look at the state of imap sync programs and was a bit
disappointed. Many older recommendations are for software that is no
longer packaged, or hard to find. And none of the ones I looked at do
something as simple as "copy these messages to this imap server".
They're all very interested in bidirectional sync, incremental updates,
and so on. But I do think one could make mbsync or offlineimap work, if
you used a dedicated folder on the server as the destination.
But yeah, I don't think you or I needs to come up with a solution there.
I was more proposing along the lines of: let's drop imap-send, and
interested people can then make a solution based on other tools, or even
spin off imap-send into its own repository.
But I get that even that is some work, and it may mean complaining
users.
-Peff