Hi Eric, I would like to take five minutes to thank you for public-inbox. It is invaluable for me in the meantime. And I think I will never be able to thank you enough for it.
Just a couple of things where it is super useful to me: - Recently, my mail provider started dropping mails left and right. They might even be addressed to me, and they never arrive in my inbox (and not even in the spam folder: they just never arrive). I spent some ten hours this past weekend to script identifying the mails in public-inbox that I never received, and to weed through them. It seems I missed some 4,000 mails. Thanks to you, I now saw those mails (although I had to delete most of them after reading only their subject, in the interest of time). - Many a times when my automated builds identified a problem with the test suite, it was a lot quicker to use public inbox to identify the mail to respond to than to use my mail program. - Sometimes, I find myself in want of replying to a past patch, but back in the day when it was sent I thought it would not be interesting to me, so I deleted it. With public-inbox, I can easily get it in raw format, i.e. put it back into my inbox so I can reply. - I cannot tell you how many times I send a link to public-inbox to my colleagues rather than forwarding a mail, because the former will give them more context (and also semi-live updates in case somebody replied to said mail after I sent the link). A couple of things in the future that public-inbox will make possible for me: - You probably are aware of my GitGitGadget endeavor, a project similar in aim to SubmitGit, but a lot more integrated with the GitHub experience (and not requiring you to hand over your mail sending credentials to AWS). One particular feature I found myself really wanting in SubmitGit (but not possible due to its one-way design): I want my Pull Requests to be closed once the patches are integrated into git.git's `master` branch. While this feature is not available in GitGitGadget yet, I am well underway there. I already have a notes ref (`commit-to-mail`, available via https://github.git/gitgitgadget/git) that annotates commits in git.git with the Message-ID of the corresponding mail. By "I have", I mean: there is an automated task that uses public-inbox to keep that ref up to date. I also have an accompanying `mail-to-commit` notes ref that maps Message-IDs back to the corresponding commit in git.git. That notes ref "annotates" the (non-existing) blob you get when piping the Message-ID with a trailing newline to `git hash-object`. Again, this is information that would be absolutely unobtainable without public-inbox. - Related, I want to annotate the GitHub Pull Requests handled by GitGitGadvget with the corresponding name of the branch in https://github.com/gitster/git. This requires that `mail-to-commit` I mentioned in the previous bullet point, and therefore would not be possible without public-inbox. - A feature I plan on introducing into GitGitGadget is to attach comments to the GitHub Pull Request when anybody replies to the patch thread sent out by GitGitGadget. Also this feature would be impossible without public-inbox. - Another really useful feature I plan on introducing is to attach comments to those PRs whenever a What's Cooking is talking about the corresponding branch. Once again, would be impossible without public-inbox. So thank you, thank you, thank you, for public-inbox! Ciao, Dscho P.S.: FWIW I added a mirror of public-inbox to https://git-for-windows.visualstudio.com/git.public-inbox, so that my automated tasks, as well as my playing around, does not stress your server too much.
