5 ms·

I don't mind the visual style of sourcehut but I find the UI very confusing. I just went to do a few common tasks and I was struggling. First I went to find a l

I don't mind the visual style of sourcehut but I find the UI very confusing. I just went to do a few common tasks and I was struggling. First I went to find a list of branches and I had to click through every tab until I landed on "refs" that had it. What does refs mean? I assume its some internal git terminology but why not just call the tab branches. I then went to find out where I could submit a PR/MR and I couldn't find any such feature. I also couldn't find a list of bugs or how to open one. I'm not really sure what case you would want to use this over GitLab/Gitea which work very well for basically every use case. Especially when you consider that you are driving away potential contributors by using this.

ddevault 6y ago
The refs tab is not called branches because it is for references. We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools. On hg.sr.ht, for example, it's named differently, because Mercurial is designed differently and has different terminology. SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such. I have no intention of building yet another GitHub clone. If you insist on everything having the same workflow, then what utility is there in different tools? Be prepared to challenge your preconceptions when learning how to use SourceHut. The documentation is thorough and has lots of tutorials to help you along the way: https://man.sr.ht/ https://man.sr.ht/ There are no pull requests or merge requests. We use email, which is how Git was designed to be used. This tutorial will get you started: https://git-send-email.io https://git-send-email.io If you just want a GitHub clone, use a GitHub clone. Don't evaluate SourceHut by that critera.
- thayne 6y ago
  > There are no pull requests or merge requests. We use email, which is how Git was designed to be used. I get that some people really like mailing lists, and I am aware of the shortcomings of the pull/merge request model. But I've never really contributed to a project that used mailing lists, and there are some problems I see with mailing list. Perhaps it's just my lack of familiarity with the workflow, but these are some advantages I think the github-style flow has: - Ability to subscribe to individual pull requests. Many mailing lists are very high volume, and afaik, it isn't possible to subscribe to individual threads. Yes I could subscribe to the list and set up filters, but that is more difficult than subscribing to individual pull requests in github, and getting the filters right could be tricky. - Ability to search by tags/labels - Automatic linking between related issues and pull requests (with backreferences) - The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list. - Highlighting changes in the diff (source hut actually does this) I'd be curious to know if proponents of the mailing list flow have anything to accomplish functionality similar to these. Or if there are any tools or tricks they use to make dealing with patch requests in email easier.
  - fluffything 6y ago
    TBH it sounds to me that you just need a better email client ? Like... that's the program that handles everything that you mentioned.
    - pcr910303 6y ago
      Well, an email client isn't a tool just for developing - it's a generic tool that has a lot of use cases. I don't think one should sacrifice features to get diff highlights or filtering PRs, nor should a generic email client try to implement out-of-the-box SourceHut filtering functionality. Yes, one can use specific filters to accomplish subscribing to a particular PR, but that's complex, and when I'm using a generic email client I can't think of how it can not be complex.
      - ignaloidas 6y ago
        Nothing is stopping you from using more than one email client.
        thayne 6y ago
        then you would need to configure filters across multiple email clients, which only makes the filter problem worse.
        mrmanner 6y ago
        I use two, with very different filters. Since I use them for different things there’s not much overlap between the configurations. The total volume of conf is probably larger than if I’d used one client only, but the user experience is also a lot better (for me) since I can use the best tool in more cases.
    - oefrha 6y ago
      The best solution to email filtering is not receiving irrelevant emails in the first place. It’s always funny seeing people bending over backwards to justify terrible inconveniences they’re merely used to. Plus, an email program that handles automatic cross referencing of tickets and commits? Where can I find that “better email client”?
- oefrha 6y ago
  > We use email, which is how Git was designed to be used. > If you insist on everything having the same workflow, then what utility is there in different tools? I'll admit many if not most git users have only ever tasted the GitHub workflow, but there are also many who have experienced the old school email workflow and the GitHub workflow and legitimately prefer the latter. Two major considerations: 1. A lot of value-add around pull requests, both in terms of organization/filtering and lifecycle features (inline comments/reviews, CI/CD integration, policy enforcement, merging from web interface, etc.). I planned to go into details here and actually wrote quite a few bullet points before realizing I can't do this topic justice without spending a lot of time to produce a huge wall of text, so please excuse me for the lack of details. (Note: not saying CI/CD integration is impossible with the email workflow, but it doesn't seem possible on sr.ht at the moment without manually pushing someone else's patch to a branch of yours -- correct me, and other implementations I have seen are nowhere as streamlined as those provided by GitHub and clones.) 2. Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete (e.g. In-Reply-To is not covered). Even the incomplete coverage highlights the complexity. Now what about the git-am side of the equation? How do I fish out a patch from my email client, any email client? How do I figure out which commit to apply the patch on top? Then there's the branching and git-am dance. Maybe it could be streamlined if you use some sort of hacker's mail client with ninja plugins, but you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly. The PR workflow, on the other hand, stays within the boundaries of push/fetch/pull/checkout, the basic operations required for working with any git remote and core competency of any git client (if you choose to use one); no ninja mail client required. hub(1) makes it even easier. I don't think "how Git was designed to be used" is a strong defense, Linus isn't almighty and what he originally designed could be improved. I can understand not being a GitHub clone, but when flexibility is a stated goal (I'm sort of reading between the lines, correct me if I'm wrong) maybe it doesn't hurt to support multiple workflows (a lot of work of course). Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table, which is in itself okay depending on your goal.
  - ddevault 6y ago
    >inline comments/reviews >CI/CD integration >merging from web interface All of this is possible and planned for or already working on SourceHut. Remember, SourceHut is an alpha - don't write it off just yet because it's not entirely complete. >Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete I intend to follow-up with git-am.io at some point, for what it's worth. And I disagree that it's incomplete: it just encourages a workflow which doesn't use In-Reply-To. It covers follow-up patches without it. >you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly My response to this is (1) you can use multiple email clients for different reasons, you don't need to give up your current one; and (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am. >Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table Popular, yes. Superior, definitely not. But leaving that aside: I am okay with leaving potential users on the table. I'm not maximizing the possible userbase of SourceHut. I'm building a platform that embodies my development principles, for people who find those principles worthwhile.
- pcr910303 6y ago
  > We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools. I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for. > There are no pull requests or merge requests. If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?
  - ddevault 6y ago
    >I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for. In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use. I don't believe that users are not capable of learning new things. In this particular case, this is the first time anyone has commented on "refs" being difficult to understand in the 1.5 years that SourceHut has been around. >If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true? Yeah, this is still true, and somewhat implemented now. The large blue button on the repo summary page can clone the repo to your account, and then be used to interactively prepare a patchset to send to the mailing list. I'm not sure how Polylactic_acid missed it, actually, unless they don't have an account. The UI only works for account holders, though the big button is replaced with instructions on how to contribute by email if you're logged out. There's a video of the process here: https://sourcehut.org/blog/2019-10-15-whats-cooking-october-2019/ https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...
    - pcr910303 6y ago
      > In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use. IMHO progressive disclosure is important, because if you want something to be widespread, beginners should be able to use SourceHut with little guidance. > I don't believe that users are not capable of learning new things. Well, for the users to learn git terminology, one has to start using git — and one of the biggest reasons is to start using git is to clone popular projects or cooperating between different people. If SourceHut is hostile (I’m not saying that it’s currently hostile, but I think it may improve) for people who don’t what a ‘ref’ is, people have to start using GitHub — and the newcomers of SourceHut becomes the very small portion of people who are already an ‘git expert’ and is interested in emailing patches. If SourceHut wants to make the email patches/other workflows that SourceHut encourages mainstream, I think it’s crucial for git newcomers to be able to use it. It’s a losing game otherwise.
- haolez 6y ago
  Out of curiosity: what do you think of the attempts to create something better than emails for communication? Maybe easier to host without getting harassed by big corps anti-spam systems. Maybe with cryptography being easier and less error prone to use. What do you think of something like Matrix?
thayne 6y ago
What I found confusing is that after finding the source code page for a project, I couldn't figure out where to go navigate to the related bug tracker, mailing list, wiki, etc. It looks like the project hub now has project pages that help with that, but the individual pages don't seem to have backlinks to the project that contains them (or at least if they do, I can't find them). But it's still a work in progress, so hopefully that will come in due time.

ddevault 6y ago

The refs tab is not called branches because it is for references. We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools. On hg.sr.ht, for example, it's named differently, because Mercurial is designed differently and has different terminology. SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such. I have no intention of building yet another GitHub clone. If you insist on everything having the same workflow, then what utility is there in different tools? Be prepared to challenge your preconceptions when learning how to use SourceHut. The documentation is thorough and has lots of tutorials to help you along the way: https://man.sr.ht/ https://man.sr.ht/ There are no pull requests or merge requests. We use email, which is how Git was designed to be used. This tutorial will get you started: https://git-send-email.io https://git-send-email.io If you just want a GitHub clone, use a GitHub clone. Don't evaluate SourceHut by that critera.

thayne 6y ago
> There are no pull requests or merge requests. We use email, which is how Git was designed to be used. I get that some people really like mailing lists, and I am aware of the shortcomings of the pull/merge request model. But I've never really contributed to a project that used mailing lists, and there are some problems I see with mailing list. Perhaps it's just my lack of familiarity with the workflow, but these are some advantages I think the github-style flow has: - Ability to subscribe to individual pull requests. Many mailing lists are very high volume, and afaik, it isn't possible to subscribe to individual threads. Yes I could subscribe to the list and set up filters, but that is more difficult than subscribing to individual pull requests in github, and getting the filters right could be tricky. - Ability to search by tags/labels - Automatic linking between related issues and pull requests (with backreferences) - The request is itself a git branch, which makes it easy to compare both the current state of the request to master, as well as see incremental changes to the request as individual commits. I'm not sure how to accomplish that in a mailing list. - Highlighting changes in the diff (source hut actually does this) I'd be curious to know if proponents of the mailing list flow have anything to accomplish functionality similar to these. Or if there are any tools or tricks they use to make dealing with patch requests in email easier.
- fluffything 6y ago
  TBH it sounds to me that you just need a better email client ? Like... that's the program that handles everything that you mentioned.
  - pcr910303 6y ago
    Well, an email client isn't a tool just for developing - it's a generic tool that has a lot of use cases. I don't think one should sacrifice features to get diff highlights or filtering PRs, nor should a generic email client try to implement out-of-the-box SourceHut filtering functionality. Yes, one can use specific filters to accomplish subscribing to a particular PR, but that's complex, and when I'm using a generic email client I can't think of how it can not be complex.
    - ignaloidas 6y ago
      Nothing is stopping you from using more than one email client.
      - thayne 6y ago
        then you would need to configure filters across multiple email clients, which only makes the filter problem worse.
        mrmanner 6y ago
        I use two, with very different filters. Since I use them for different things there’s not much overlap between the configurations. The total volume of conf is probably larger than if I’d used one client only, but the user experience is also a lot better (for me) since I can use the best tool in more cases.
  - oefrha 6y ago
    The best solution to email filtering is not receiving irrelevant emails in the first place. It’s always funny seeing people bending over backwards to justify terrible inconveniences they’re merely used to. Plus, an email program that handles automatic cross referencing of tickets and commits? Where can I find that “better email client”?
oefrha 6y ago
> We use email, which is how Git was designed to be used. > If you insist on everything having the same workflow, then what utility is there in different tools? I'll admit many if not most git users have only ever tasted the GitHub workflow, but there are also many who have experienced the old school email workflow and the GitHub workflow and legitimately prefer the latter. Two major considerations: 1. A lot of value-add around pull requests, both in terms of organization/filtering and lifecycle features (inline comments/reviews, CI/CD integration, policy enforcement, merging from web interface, etc.). I planned to go into details here and actually wrote quite a few bullet points before realizing I can't do this topic justice without spending a lot of time to produce a huge wall of text, so please excuse me for the lack of details. (Note: not saying CI/CD integration is impossible with the email workflow, but it doesn't seem possible on sr.ht at the moment without manually pushing someone else's patch to a branch of yours -- correct me, and other implementations I have seen are nowhere as streamlined as those provided by GitHub and clones.) 2. Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete (e.g. In-Reply-To is not covered). Even the incomplete coverage highlights the complexity. Now what about the git-am side of the equation? How do I fish out a patch from my email client, any email client? How do I figure out which commit to apply the patch on top? Then there's the branching and git-am dance. Maybe it could be streamlined if you use some sort of hacker's mail client with ninja plugins, but you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly. The PR workflow, on the other hand, stays within the boundaries of push/fetch/pull/checkout, the basic operations required for working with any git remote and core competency of any git client (if you choose to use one); no ninja mail client required. hub(1) makes it even easier. I don't think "how Git was designed to be used" is a strong defense, Linus isn't almighty and what he originally designed could be improved. I can understand not being a GitHub clone, but when flexibility is a stated goal (I'm sort of reading between the lines, correct me if I'm wrong) maybe it doesn't hurt to support multiple workflows (a lot of work of course). Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table, which is in itself okay depending on your goal.
- ddevault 6y ago
  >inline comments/reviews >CI/CD integration >merging from web interface All of this is possible and planned for or already working on SourceHut. Remember, SourceHut is an alpha - don't write it off just yet because it's not entirely complete. >Difficulties around git-send-email and git-am. git-send-email.io only covers half of the equation and coverage isn't complete I intend to follow-up with git-am.io at some point, for what it's worth. And I disagree that it's incomplete: it just encourages a workflow which doesn't use In-Reply-To. It covers follow-up patches without it. >you'll have a hard time convincing most people to give up their preferred mail client just because it's not git-friendly My response to this is (1) you can use multiple email clients for different reasons, you don't need to give up your current one; and (2) you don't need a special email client to apply patches from lists.sr.ht, every patchset page has a little CLI command you can copy+run to fetch the patch with curl and feed it to git am. >Rejecting a popular and arguably superior (for many if not most git users) workflow means leaving a lot of potential users on the table Popular, yes. Superior, definitely not. But leaving that aside: I am okay with leaving potential users on the table. I'm not maximizing the possible userbase of SourceHut. I'm building a platform that embodies my development principles, for people who find those principles worthwhile.
pcr910303 6y ago
> We use git terminology deliberately, because it is a tool for git, and you should not be afraid of understanding your tools. I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for. > There are no pull requests or merge requests. If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true?
- ddevault 6y ago
  >I know git internals enough to know what a ‘ref’ is, but IMHO it’s a word that’s pretty hard for an average git user to know. I would suggest at least having a tooltip with some text like ‘Git references: branches, tags, etc...’ so that beginners can understand what it‘s used for. In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use. I don't believe that users are not capable of learning new things. In this particular case, this is the first time anyone has commented on "refs" being difficult to understand in the 1.5 years that SourceHut has been around. >If I remember correctly, I thought that a way to submit patches through a web UI was being developed... Is it still true? Yeah, this is still true, and somewhat implemented now. The large blue button on the repo summary page can clone the repo to your account, and then be used to interactively prepare a patchset to send to the mailing list. I'm not sure how Polylactic_acid missed it, actually, unless they don't have an account. The UI only works for account holders, though the big button is replaced with instructions on how to contribute by email if you're logged out. There's a video of the process here: https://sourcehut.org/blog/2019-10-15-whats-cooking-october-2019/ https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...
  - pcr910303 6y ago
    > In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use. IMHO progressive disclosure is important, because if you want something to be widespread, beginners should be able to use SourceHut with little guidance. > I don't believe that users are not capable of learning new things. Well, for the users to learn git terminology, one has to start using git — and one of the biggest reasons is to start using git is to clone popular projects or cooperating between different people. If SourceHut is hostile (I’m not saying that it’s currently hostile, but I think it may improve) for people who don’t what a ‘ref’ is, people have to start using GitHub — and the newcomers of SourceHut becomes the very small portion of people who are already an ‘git expert’ and is interested in emailing patches. If SourceHut wants to make the email patches/other workflows that SourceHut encourages mainstream, I think it’s crucial for git newcomers to be able to use it. It’s a losing game otherwise.
haolez 6y ago
Out of curiosity: what do you think of the attempts to create something better than emails for communication? Maybe easier to host without getting harassed by big corps anti-spam systems. Maybe with cryptography being easier and less error prone to use. What do you think of something like Matrix?

thayne 6y ago

What I found confusing is that after finding the source code page for a project, I couldn't figure out where to go navigate to the related bug tracker, mailing list, wiki, etc. It looks like the project hub now has project pages that help with that, but the individual pages don't seem to have backlinks to the project that contains them (or at least if they do, I can't find them). But it's still a work in progress, so hopefully that will come in due time.