3 ms·

>Yeah but my email client can't show me nice diffs https://l.sr.ht/QlVR.png https://l.sr.ht/QlVR.png >let me comment on line numbers like GitLab/Hub can http

• umvi 6y ago
  > But at the end of the day, if this workflow is not for you, there are a half-dozen other platforms you could be using. I've never actually used an email-based workflow, but I'm trying to understand why people might prefer it over PRs. SourceHut gets a lot of love on this site and I feel like I am missing out. But every time I look into it, I feel like there is something I'm not quite grasping.
  • ddevault 6y ago
    Try this, it'll walk you through the contribution process: https://git-send-email.io https://git-send-email.io I like email because it's very efficient, both as a contributor and a maintainer. It can fire off a patch with a single command, and reviewing lots of patches is easy, too. It's also distributed and federated by its very nature, which makes it fault tolerant and keeps your data from being locked up in a centralized/proprietary database.
    • e12e 6y ago
      As a former pine user, now trapped behind o365 web client, top posting and all - what email client are you currently using? I've toyed with going over to mutt, looked at alpine, and mulled over trying notmuch, lumail or even plain nmh. Ed: for the mail curious, as some of these can be tricky to search for: http://www.nongnu.org/nmh/ http://www.nongnu.org/nmh/ https://repo.or.cz/alpine.git https://repo.or.cz/alpine.git https://notmuchmail.org/#index4h2 https://notmuchmail.org/#index4h2 https://lumail.org/ https://lumail.org/
      • ddevault 6y ago
        I wrote my own mail client: https://aerc-mail.org https://aerc-mail.org
  • servilio 6y ago
    I use Github and Gitlab on a daily basis, and participated (and still follow) in a project with an e-mail based workflows, the notmuch[1] project. I find that the following are better in an e-mail based workflow: - Reviewing Threaded e-mail discussions are the best for following and/or discussing pull requests. Commits or comments no longer relevant can be hidden/collapsed to allow you to focus on what you are interested or is left to review. This is still not possible fully in either Gitlab or Github. - Multiple versions of a pull request Only Gitlab has support for multiple versions of a merge request. In Github there is no history of what the previous versions of the code were (or at least you cannot not explicitly compare them as in Gitlab) - Merging into multiple branches Though not enabled directly by an e-mail based workflow, with Gitlab/Github there is no way to ask the same set of changes to be merged into different branches in the same MR, you have to open two, and then you might issues with tools that integrate with them as they might have done the assumption that one branch is not used in two different MRs. So, even though daggy fixes[2] are possible, the norm seems to be to cherry pick. - Custom styling This varies with the e-mail client, but still is way better than any web interface. [1] https://notmuchmail.org/ https://notmuchmail.org/ [2] https://wiki.monotone.ca/DaggyFixes/ https://wiki.monotone.ca/DaggyFixes/