On Wed, Feb 08, 2023 at 02:06:55AM +0100, Ævar Arnfjörð Bjarmason wrote: > > 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