4 ms·

> On the actual post: what prevents one from using `git am` locally and then pushing the changes to GitHub? Absolutely nothing. His entire 'Github vs Git' thes

> On the actual post: what prevents one from using `git am` locally and then pushing the changes to GitHub? Absolutely nothing. His entire 'Github vs Git' thesis is a false dichotomy.

dfc 14y ago
"false dichotomy" How can you commit to the linux kernel using github's interface? I have not seen a button for `git send-email`.
- quaunaut 14y ago
  Forgive me, I'm not nearly as familiar with the system as others, but couldn't you just clone the repo on your own system, then send that command from your own bash? It isn't using Github, yes, but then again that system setup doesn't seem like it's using Github either.
  - dfc 14y ago
    I think the point of the linked story is that you can use github seamlessly to collaborate with other GH projects but you have to use your local git installation for interacting with non-gh projects.
    - lotyrin 14y ago
      You have to use your own local git for doing anything non-trivial. Github does not intend to replace your CLI, it intends to augment it. Reimplementing send-email/am would be a waste of their effort toward their true goal.
- deleted 14y ago
  [deleted]
- ceol 14y ago
  Apparently this isn't obvious, but when you push your repo to Github, you aren't actually handing complete control of it over to them. You can still `git send-email` from your CLI.
- mh- 14y ago
  I'm not sure I understand the basis for your conclusion.. There's a lot of git operations you can't do with the Github web interface. How do you do a non-ff merge? A rebase? You use the git cli.
  - dfc 14y ago
    I think that is the thesis of the linked story. I did not write the linked story nor am I in complete agreement with the author. But I think that the thesis is that there is the github way and then there is the git cli way. To use the author's analogy to gmail, what actions do you drop to the shell to complete instead of using gmail's interface.
    - msbarnett 14y ago
      > But I think the thesis is there is the github way and then there is the goit cli way. Which is, again, a false dichotomy. Github is a remote repo. In git you always also have your own local repo, and things like 'git am' and 'git send-email' (and 'git rebase --interactive', and 'git bisect', and any other non-trivial use of git) are operations that you would always want to be performing locally before pushing it out to a remote repository. That there's no interface to perform these things on Github doesn't mean that Github is trying to engage in vendor lock-in, it's just a reflection of the reality of the fact that you should be doing that stuff to your local private repo, with your local client.
    - mh- 14y ago
      I think the difference is that gmail wasn't the first simplification (web-based or otherwise) of email. Remember when people used to sign (and/or encrypt) their emails with PGP/GPG? I'm not aware of a way to do that in gmail in any realistic sense. I do remember, however, many early webmail clients barely supporting even small attachments. Some didn't support multipart. Eventually, as webmail providers improved, the userbase decided the trade-off of losing the low-level access for the usability advances was worthwhile. I think email is an apt analogy. GitHub is the first highly-successful incarnation of its kind. There are already credible competitors (albeit with much smaller user counts), and there will be more. GH has made a business decision on what features they spend time on. Other competitors will arrive at different decisions. Developers, along with popular open source projects, will go to the providers that support their needs.
- handelaar 14y ago
  Perhaps the github people decided -- since in order to have a `git send-email` button you must first have actually committed a repo from your own machine, and that your CLI/local client has the facililty already -- that the feature being moaned about here was... what's the word?... optional.
srl 14y ago
In theory, nothing. In practice, most github users don't know how to use `git am`, and won't accept contributions but through github pull requests (or at least will get very annoyed). In general, open-source projects place the onus on the contributor to make sure the contribution is packaged appropriately, for better or worse. Emailing patches around works very well, and modern VCSes have splendid support for it. If you want to contribute to a project on github, you need to abandon that.
- mh- 14y ago
  >place the onus on the contributor to make sure the contribution is packaged appropriately appropriately according to the standards of that project. if using GH pull requests was such a barrier to entry, contributors wouldn't and you'd see an exodus from using them. I haven't seen this.
- msbarnett 14y ago
  > In general, open-source projects place the onus on the contributor to make sure the contribution is packaged appropriately, for better or worse. Emailing patches around works very well, and modern VCSes have splendid support for it. If you want to contribute to a project on github, you need to abandon that. Rather: if you want to contribute to a project on github, and that project does not accept emailed patches for contributions, you need to abandon that. If the project didn't accept pull requests, you'd need to abandon pull requests. This has absolutely nothing to do with Github, and everything to do with the preferences of the project maintainers and the reality that if you want to contribute to something, it's up to you to conform to its standards, not it to conform to your preferences. Pull requests are popular with project maintainers simply because they're a very low-friction way to accept contributions.
  - dasil003 14y ago
    Also, if you email the maintainers a patch and an explanation about why you don't use Github and humbly ask them if they'd accept the patch, I think there's a good likelihood they will if the patch is good.

> On the actual post: what prevents one from using `git am` locally and then pushing the changes to GitHub? Absolutely nothing. His entire 'Github vs Git' thesis is a false dichotomy.

dfc 14y ago

"false dichotomy" How can you commit to the linux kernel using github's interface? I have not seen a button for `git send-email`.

quaunaut 14y ago
Forgive me, I'm not nearly as familiar with the system as others, but couldn't you just clone the repo on your own system, then send that command from your own bash? It isn't using Github, yes, but then again that system setup doesn't seem like it's using Github either.
- dfc 14y ago
  I think the point of the linked story is that you can use github seamlessly to collaborate with other GH projects but you have to use your local git installation for interacting with non-gh projects.
  - lotyrin 14y ago
    You have to use your own local git for doing anything non-trivial. Github does not intend to replace your CLI, it intends to augment it. Reimplementing send-email/am would be a waste of their effort toward their true goal.
deleted 14y ago
[deleted]
ceol 14y ago
Apparently this isn't obvious, but when you push your repo to Github, you aren't actually handing complete control of it over to them. You can still `git send-email` from your CLI.
mh- 14y ago
I'm not sure I understand the basis for your conclusion.. There's a lot of git operations you can't do with the Github web interface. How do you do a non-ff merge? A rebase? You use the git cli.
- dfc 14y ago
  I think that is the thesis of the linked story. I did not write the linked story nor am I in complete agreement with the author. But I think that the thesis is that there is the github way and then there is the git cli way. To use the author's analogy to gmail, what actions do you drop to the shell to complete instead of using gmail's interface.
  - msbarnett 14y ago
    > But I think the thesis is there is the github way and then there is the goit cli way. Which is, again, a false dichotomy. Github is a remote repo. In git you always also have your own local repo, and things like 'git am' and 'git send-email' (and 'git rebase --interactive', and 'git bisect', and any other non-trivial use of git) are operations that you would always want to be performing locally before pushing it out to a remote repository. That there's no interface to perform these things on Github doesn't mean that Github is trying to engage in vendor lock-in, it's just a reflection of the reality of the fact that you should be doing that stuff to your local private repo, with your local client.
  - mh- 14y ago
    I think the difference is that gmail wasn't the first simplification (web-based or otherwise) of email. Remember when people used to sign (and/or encrypt) their emails with PGP/GPG? I'm not aware of a way to do that in gmail in any realistic sense. I do remember, however, many early webmail clients barely supporting even small attachments. Some didn't support multipart. Eventually, as webmail providers improved, the userbase decided the trade-off of losing the low-level access for the usability advances was worthwhile. I think email is an apt analogy. GitHub is the first highly-successful incarnation of its kind. There are already credible competitors (albeit with much smaller user counts), and there will be more. GH has made a business decision on what features they spend time on. Other competitors will arrive at different decisions. Developers, along with popular open source projects, will go to the providers that support their needs.
handelaar 14y ago
Perhaps the github people decided -- since in order to have a `git send-email` button you must first have actually committed a repo from your own machine, and that your CLI/local client has the facililty already -- that the feature being moaned about here was... what's the word?... optional.

srl 14y ago

In theory, nothing. In practice, most github users don't know how to use `git am`, and won't accept contributions but through github pull requests (or at least will get very annoyed). In general, open-source projects place the onus on the contributor to make sure the contribution is packaged appropriately, for better or worse. Emailing patches around works very well, and modern VCSes have splendid support for it. If you want to contribute to a project on github, you need to abandon that.

mh- 14y ago
>place the onus on the contributor to make sure the contribution is packaged appropriately appropriately according to the standards of that project. if using GH pull requests was such a barrier to entry, contributors wouldn't and you'd see an exodus from using them. I haven't seen this.
msbarnett 14y ago
> In general, open-source projects place the onus on the contributor to make sure the contribution is packaged appropriately, for better or worse. Emailing patches around works very well, and modern VCSes have splendid support for it. If you want to contribute to a project on github, you need to abandon that. Rather: if you want to contribute to a project on github, and that project does not accept emailed patches for contributions, you need to abandon that. If the project didn't accept pull requests, you'd need to abandon pull requests. This has absolutely nothing to do with Github, and everything to do with the preferences of the project maintainers and the reality that if you want to contribute to something, it's up to you to conform to its standards, not it to conform to your preferences. Pull requests are popular with project maintainers simply because they're a very low-friction way to accept contributions.
- dasil003 14y ago
  Also, if you email the maintainers a patch and an explanation about why you don't use Github and humbly ask them if they'd accept the patch, I think there's a good likelihood they will if the patch is good.