4 ms·

If you are also down with requiring that your would-be contributors conform to his preference for email patches. https://man.sr.ht/git.sr.ht/send-email.md https

by kixiQu 4y ago

If you are also down with requiring that your would-be contributors conform to his preference for email patches. https://man.sr.ht/git.sr.ht/send-email.md https://man.sr.ht/git.sr.ht/send-email.md "SourceHut is not GitHub/GitLab/Gitea, and you would be ill-advised to treat it as such." https://news.ycombinator.com/item?id=23038520 https://news.ycombinator.com/item?id=23038520 (And therefore, perhaps, ill-advised to recommend it as such)

lupire 4y ago
Does Drew prefer email, or prefer not doing more work than he already does?
- smaudet 4y ago
  Hmm - review is not a part of git, in fact it is antithetical to git (concept from cvs/svn with centralized systems). A pull request, literally, need only be moving code from one repo to another. The signaling mechanism etc. are not and shouldn't be specified by git. How code moves around should be dictated by your organism, copyright, access levels, not some guy's interpretation of what "pull request" means. That means, yes in some instances there is no 'master' version of the software, there are multiple flavors with different release characteristics. E-mail I suppose is an adequate communication medium, if people want a specific review mechanism and triggers adding one to source hut (assuming FOSS) shouldn't be hard, perhaps the authors intention is to make it difficult to regress to a centralized model.
  - ddevault 4y ago
    >Hmm - review is not a part of git Email-based review tools are built-in to git. git format-patch, send-email, am, imap-send, etc.
    - pferde 4y ago
      Those are tools to facilitate moving the code from one repo to another, not to facilitate a review of that code. So I think the GP's point stands.
      - ddevault 4y ago
        I mean, it facilitates code review as well. You just reply to the email. This is how Linux is developed, for instance.
        pferde 4y ago
        Yes, but you do not reply via git. You review the patches in the MUA of your choice (outside of git) or in editor or IDE of your choice, after applying them in your local repository clone (applied maybe by git, maybe by the "patch" command, but viewed and evaluated completely without git), then you compose a reply in your MUA or maybe have a direct chat with someone about it (again, outside of git). Git only comes in play when the review is finished, and it's time to commit the changes to your repository. So I claim that git does not have tools for reviewing pull requests or patch sets, only for managing them on either end of the pipeline - creating them, sending them, and applying them. Which, to be clear, is not a criticism of git, as I do not think git should grow such review tools.
        ddevault 4y ago
        Alright, sure, but you're picking nits and I'm not sure what your underlying point is.
        smaudet 4y ago
        It isn't picking nits, git does patch management, there is nothing and shouldn't be for review. It matters because where you assign your responsibilities is the difference between spaghetti code/architecture and a well designed one. If you think this is nitpicking, I encourage you to (re)view the general sofware concepts of cohesion and coupling. (Part of) gits success is it is a tool focused on doing one thing well - I believe Linus is on record as saying the other tooling (commercial/svn) largely failed because they were not really focused on source control i.e. patch management. Its part of the reason he constructed it in the first place, the tool he was using was overcomplex and bad at doing simple things. Github's success until this point has been largely that it focused on building review infrastructure. It's based on git, giving it flexibility akin to being based on e.g. http, but it's core is review and facilities in support of that e.g. code search. It's a very particular type of review aimed at a specific audience, but it's not git, nor should it be.
ddevault 4y ago
SourceHut author here. Not sure what you're trying to say. The opposite is also true: using GitHub requires that your would-be contributors conform to the pull request workflow instead -- and many people prefer emails. If anyone is skeptical about the email workflow, here's a write-up from another skeptic: https://blog.brixit.nl/git-email-flow-versus-github-flow/ https://blog.brixit.nl/git-email-flow-versus-github-flow/
- kixiQu 4y ago
  What I am saying is that, both in what I've seen and what you've stated, SourceHut is emphatically not trying to be "Github but just without the gamification elements", so if that's what people are looking for, they probably want to look elsewhere.
  - cxr 4y ago
    > "Github but just without the gamification elements" Where did this quote come from? You just made it up? You're obviously trying to offer a retort/rebuff of some argument. But whose? Which argument?
    - kixiQu 4y ago
      No, I am not trying to retort/rebuff, and this thread seems unexpectedly confrontational. The quotation paraphrases the context of the exchange, which I will again summarize in case it is not adequately clear in itself: There was a commenter that said that they don't like how GH has introduced gamification elements, id 33310374. Then there was a commenter that said that the first commenter should therefore use SourceHut, because it stands in opposition to gamification, id 33311082. This exchange positions SourceHut as "Github, but without gamification elements", which I am putting in quotes to indicate it is a single coherent concept. I am pointing out that SourceHut is not designed to be a Github-like, as with its opinionated design choices around PRs, and I quote Drew being pretty explicit about that.
      - cxr 4y ago
notpushkin 4y ago
SourceHut is very modular though. Could we make a separate app that implements pull requests? :thinking:
MisterTea 4y ago
> conform to his preference for email patches How is a time tested method of sending patches conforming? If you don't like the method or cant be arsed to learn it then find something else or roll your own.
- kixiQu 4y ago
  Right – something else like Github, the component under discussion, which is dissimilar to SourceHut in more ways than the gamification elements under discussion.

by kixiQu 4y ago

lupire 4y ago

Does Drew prefer email, or prefer not doing more work than he already does?

smaudet 4y ago
Hmm - review is not a part of git, in fact it is antithetical to git (concept from cvs/svn with centralized systems). A pull request, literally, need only be moving code from one repo to another. The signaling mechanism etc. are not and shouldn't be specified by git. How code moves around should be dictated by your organism, copyright, access levels, not some guy's interpretation of what "pull request" means. That means, yes in some instances there is no 'master' version of the software, there are multiple flavors with different release characteristics. E-mail I suppose is an adequate communication medium, if people want a specific review mechanism and triggers adding one to source hut (assuming FOSS) shouldn't be hard, perhaps the authors intention is to make it difficult to regress to a centralized model.
- ddevault 4y ago
  >Hmm - review is not a part of git Email-based review tools are built-in to git. git format-patch, send-email, am, imap-send, etc.
  - pferde 4y ago
    Those are tools to facilitate moving the code from one repo to another, not to facilitate a review of that code. So I think the GP's point stands.
    - ddevault 4y ago
      I mean, it facilitates code review as well. You just reply to the email. This is how Linux is developed, for instance.
      - pferde 4y ago
        Yes, but you do not reply via git. You review the patches in the MUA of your choice (outside of git) or in editor or IDE of your choice, after applying them in your local repository clone (applied maybe by git, maybe by the "patch" command, but viewed and evaluated completely without git), then you compose a reply in your MUA or maybe have a direct chat with someone about it (again, outside of git). Git only comes in play when the review is finished, and it's time to commit the changes to your repository. So I claim that git does not have tools for reviewing pull requests or patch sets, only for managing them on either end of the pipeline - creating them, sending them, and applying them. Which, to be clear, is not a criticism of git, as I do not think git should grow such review tools.
        ddevault 4y ago
        Alright, sure, but you're picking nits and I'm not sure what your underlying point is.
        smaudet 4y ago
        It isn't picking nits, git does patch management, there is nothing and shouldn't be for review. It matters because where you assign your responsibilities is the difference between spaghetti code/architecture and a well designed one. If you think this is nitpicking, I encourage you to (re)view the general sofware concepts of cohesion and coupling. (Part of) gits success is it is a tool focused on doing one thing well - I believe Linus is on record as saying the other tooling (commercial/svn) largely failed because they were not really focused on source control i.e. patch management. Its part of the reason he constructed it in the first place, the tool he was using was overcomplex and bad at doing simple things. Github's success until this point has been largely that it focused on building review infrastructure. It's based on git, giving it flexibility akin to being based on e.g. http, but it's core is review and facilities in support of that e.g. code search. It's a very particular type of review aimed at a specific audience, but it's not git, nor should it be.

ddevault 4y ago

SourceHut author here. Not sure what you're trying to say. The opposite is also true: using GitHub requires that your would-be contributors conform to the pull request workflow instead -- and many people prefer emails. If anyone is skeptical about the email workflow, here's a write-up from another skeptic: https://blog.brixit.nl/git-email-flow-versus-github-flow/ https://blog.brixit.nl/git-email-flow-versus-github-flow/

kixiQu 4y ago
What I am saying is that, both in what I've seen and what you've stated, SourceHut is emphatically not trying to be "Github but just without the gamification elements", so if that's what people are looking for, they probably want to look elsewhere.
- cxr 4y ago
  > "Github but just without the gamification elements" Where did this quote come from? You just made it up? You're obviously trying to offer a retort/rebuff of some argument. But whose? Which argument?
  - kixiQu 4y ago
    No, I am not trying to retort/rebuff, and this thread seems unexpectedly confrontational. The quotation paraphrases the context of the exchange, which I will again summarize in case it is not adequately clear in itself: There was a commenter that said that they don't like how GH has introduced gamification elements, id 33310374. Then there was a commenter that said that the first commenter should therefore use SourceHut, because it stands in opposition to gamification, id 33311082. This exchange positions SourceHut as "Github, but without gamification elements", which I am putting in quotes to indicate it is a single coherent concept. I am pointing out that SourceHut is not designed to be a Github-like, as with its opinionated design choices around PRs, and I quote Drew being pretty explicit about that.
    - cxr 4y ago

notpushkin 4y ago

SourceHut is very modular though. Could we make a separate app that implements pull requests? :thinking:

MisterTea 4y ago

> conform to his preference for email patches How is a time tested method of sending patches conforming? If you don't like the method or cant be arsed to learn it then find something else or roll your own.

kixiQu 4y ago
Right – something else like Github, the component under discussion, which is dissimilar to SourceHut in more ways than the gamification elements under discussion.