Email and Git = <3

1

GitHub CLI

In case of GitHub you have this for example : https://cli.github.com/ It is often used in GitHub CI workflows.

#Productivity #Git #Code Collaboration 104 social mentions

2

NeoMutt

[1]: https://neomutt.org/ > - The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. Yes, for sending a new revision this is highly wanted – please do NOT send new patch revision to the same thread, that just crowds review and adds nothing. Simply add a changelog to the previous revision in the cover-letter and/or in each patch, i.e., after the message, below "--" and before the diff-stat, as there they won't get into git, such changes are meta info relevant for review, not for the git history. > - Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version. I have reviewed <i>lots</i> of patches via mailing list, it's really nice and depending on the patch one can review directly inline or apply (save + `git am`, or directly `git am` depending on your mailer). IMO much higher quality of life than with the classic Git(La|Hu)b forges. > - Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge". No it really isn't, I'm doing that since years a dozen+ time a day, and it is as easy now as it was back then when I started.

#Email #Email Clients #Calendar 10 social mentions

3

aerc

You have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline. > - You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution. You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/ If you're interested, see also https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started And sure subscribing for a drive by submission is rather overkill, but if one contributes more than a few patches, setting up a filter is to easy with mailing lists that I don't think one can just hand wave that away as an "unreasonable" solution. List have a dedicated List-Id header, so one can easily filter them in a targeted way. What I want to convey actually is, that yes, there can be improvements made here, but doing so isn't impossible just because the message medium is decentralized mail vs. a centralized HTTP API. - Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email. Hard disagree on that being the general case. Even getting Thunderbird to send plaintext is simple and only one setting, and there are mailers like aerc [0] or neomutt that are really well suited for an integrated mail + apply + review setup. But sure, there are some bad apples, especially most web mailer. [0]: https://aerc-mail.org/.

#Email #Email Clients #Calendar 18 social mentions

A few comments in-line, but I don't want to "sell" anything to you, so just FWIW. > The amount of "gotchas" in this process and the tooling required just to use git + email seems insane to me. The base system is really, really simple, but there are some common rules/guidelines that just help when working together, and those are required for forge based workflows too (or do you like a single commit touching a dozen completely different, unrelated things, or just no info at all in the commit message, or pull request, for why a change was done). The core thing from this workflow is using `git send-email --to=mailing@list.example.com <commit-revision>`, the rest are a few details, possible slightly intimidating if viewed from a distant, but each separate and easy to master/implement on it's own – and most are a "set up once, be done thing", so not constant work. > If it works for you, great, but I don't expect a new hire (experienced or not) to pickup this flow and run with it. As mentioned in another comment: We hired over 15 people in the last year, most of them had no experience with git send-email and mailing list development, but they all accustomed fast and after a few weeks most of them stated they find it nicer (as in simpler, less clutter quicker to do submit own work or review others) - I myself started out over eight years ago at this place, i.e., without much experience in mail based development, and I never ran into bigger problems – on the contrary, this workflow felt like a breadth of fresh air compared to what was I used before (mostly GitHub and GitLab). Note: this works not only for small to medium, but also is the only way that actually works for the biggest projects in the world (e.g., Linux or QEMU). Just to be sure: I do not say mail(ing list) based development workflow is Just Perfect™, it sure has its problems and can be improved, and may we get some good web GUIs that tie a few of the components together, currently I see https://sourcehut.org/ as strong contender here.

#Code Collaboration #Git #VCS 55 social mentions