3 ms·

Aside from the "proprietary bad" arguments (which is enough to get traction on HN), there are a bunch of practical reasons: 1. It's faster. Mr. Devault, Sourc

by _vbdg 6y ago

Aside from the "proprietary bad" arguments (which is enough to get traction on HN), there are a bunch of practical reasons: 1. It's faster. Mr. Devault, Sourcehut's author, runs a benchmark site that demonstrates this: https://forgeperf.org/ https://forgeperf.org/ 2. The e-mail based workflow is (in my opinion) superior; I don't have to use some clunky web interface. 3. I can run it myself, on-premise, for free.

xori 6y ago
Unfortunately the actually git "push"ing of code is slower. I'm a paying sr.ht member and that's the one thing I wish was faster.
- ddevault 6y ago
  As of when? It was slow for a while, but we did a bunch of performance improvements and it's much better now.
umvi 6y ago
> 2. The e-mail based workflow is (in my opinion) superior; I don't have to use some clunky web interface. Yeah but my email client can't show me nice diffs and let me comment on line numbers like GitLab/Hub can... Plus I I don't really understand SH's decision not to support PRs, which seem fundamental to most workflows. I think PRs are far superior than spamming up my inbox and using esoteric git email commands To be fair, I've never actually tried an email-based workflow, but in my mind it involves a lot of emails and reply-alls and just general clutter and an absence of syntax highlighting, pinpoint line commenting, side-by-side diff and all the other nice things the GitLab/Hub provide with PRs.
- ddevault 6y ago
  >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 https://l.sr.ht/cz3L.png https://l.sr.ht/cz3L.png These are also being added to the web UI: https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/10253 https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/10253 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.
  - 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/

by _vbdg 6y ago

xori 6y ago

Unfortunately the actually git "push"ing of code is slower. I'm a paying sr.ht member and that's the one thing I wish was faster.

ddevault 6y ago
As of when? It was slow for a while, but we did a bunch of performance improvements and it's much better now.

umvi 6y ago

> 2. The e-mail based workflow is (in my opinion) superior; I don't have to use some clunky web interface. Yeah but my email client can't show me nice diffs and let me comment on line numbers like GitLab/Hub can... Plus I I don't really understand SH's decision not to support PRs, which seem fundamental to most workflows. I think PRs are far superior than spamming up my inbox and using esoteric git email commands To be fair, I've never actually tried an email-based workflow, but in my mind it involves a lot of emails and reply-alls and just general clutter and an absence of syntax highlighting, pinpoint line commenting, side-by-side diff and all the other nice things the GitLab/Hub provide with PRs.

ddevault 6y ago
>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 https://l.sr.ht/cz3L.png https://l.sr.ht/cz3L.png These are also being added to the web UI: https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/10253 https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/10253 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.
- 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/