4 ms·

> Git still works great. Of course, for people that know how to use it. I'd argue that the heavy use of Github combined with the adoption of advanced Git workf

> Git still works great. Of course, for people that know how to use it. I'd argue that the heavy use of Github combined with the adoption of advanced Git workflows is currently the biggest threat to open source. There's no such thing as "submitting a patch" these days. You're expected to be a master of a project's Github workflow to contribute. Most of us (myself included, with a few exceptions) just don't bother.

compsciphd 6y ago
I dont understand this issue. I'd argue that github PR model has simplified "submitting a patch" to a tremendous degree.
- xiphias2 6y ago
  Github and git are very different. Github is easyer to use, but doesn't cover all of git's use cases. So actually I'm all for reworking the base commands to support a workflow more similar to GitHub's, but still distributed.
- u801e 6y ago
  Before Github, submitting a patch required reading some documentation in the project about how to submit patches, set up one's git config to properly generate the patches and email them. Then came the part of actually making the changes, generating the patches and running a git command to submit them. With Github, one has to fork the project, run some commands to clone the repo from the fork, make the changes, push them, and then go back to the web interface to create the pull request.
  - gnufx 6y ago
    It didn't even require that. You fixed something from the immediately-buildable tarball that you'd rebuilt and tested, or even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup. You didn't have pull 100Mb of git stuff, figure out how to rebuild the build framework, find you hadn't got the submodules, prat about with a pull request, and then whatever demands it makes of you, etc. I was fine with that as a maintainer too, on three very active major projects at one time (using a 48Mb Pentium 1). A maintainer's job is partly to make it easy for contributors, not for the maintainer, but tending the contributors will help in the end.
    - u801e 6y ago
      > You fixed something from the immediately-buildable tarball that you'd rebuilt and tested That entirely depends on whether the necessary libraries and headers are installed on the system you're using. > even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup Unless someone uses emacs and gnus or something similar, email clients could end up mangling the diff unless it was sent as an attachment (which would make reviewing the code and posting an inline response more difficult).
  - Leherenn 6y ago
    Both seems non perfect to me. Having to set up one's git config or having to fork a repo seem to be accidental complexity is both cases.
    - u801e 6y ago
      To be fair, setting up one's git config is a one time step. But there is a bit of effort required to keep one's GitHub fork up to date relative to the repository it was forked from.
      - compsciphd 6y ago
        git fetch upstream ; git rebase -i upstream/master isn't that hard.
        u801e 6y ago
        It depends on whether the histories have diverged and how many conflicts there are. A lot of people aren't very proficient with the use of git and will have problems (e.g., running git pull) and creating a merge commit in their branch or having conflicts they need to resolve. The next time they open a PR using that branch, it will have commits that will clutter the branch.
tomcooks 6y ago
Isn't this "knowing how to use it" come with the usual dose of RTFM and/or trying things? Moreover, I suggest you fork the project and apply your own modifications instead of worrying about a GitHub project administrator to accept your changes
throwaway894345 6y ago
Don’t you just need to open a pull request? Or is there more ceremony that I’m missing?
shred45 6y ago
What you says is true, it can be very difficult to submit ad-hoc patches to large projects. In my experience, however, this has been due to brittle, undocumented automated checks and newbie-hostile maintainers who have built a complex contribution process. I'm not convinced that a different version control system would change this. There are also many projects on GitHub that are very pleasant to work with.

compsciphd 6y ago

I dont understand this issue. I'd argue that github PR model has simplified "submitting a patch" to a tremendous degree.

xiphias2 6y ago
Github and git are very different. Github is easyer to use, but doesn't cover all of git's use cases. So actually I'm all for reworking the base commands to support a workflow more similar to GitHub's, but still distributed.
u801e 6y ago
Before Github, submitting a patch required reading some documentation in the project about how to submit patches, set up one's git config to properly generate the patches and email them. Then came the part of actually making the changes, generating the patches and running a git command to submit them. With Github, one has to fork the project, run some commands to clone the repo from the fork, make the changes, push them, and then go back to the web interface to create the pull request.
- gnufx 6y ago
  It didn't even require that. You fixed something from the immediately-buildable tarball that you'd rebuilt and tested, or even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup. You didn't have pull 100Mb of git stuff, figure out how to rebuild the build framework, find you hadn't got the submodules, prat about with a pull request, and then whatever demands it makes of you, etc. I was fine with that as a maintainer too, on three very active major projects at one time (using a 48Mb Pentium 1). A maintainer's job is partly to make it easy for contributors, not for the maintainer, but tending the contributors will help in the end.
  - u801e 6y ago
    > You fixed something from the immediately-buildable tarball that you'd rebuilt and tested That entirely depends on whether the necessary libraries and headers are installed on the system you're using. > even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup Unless someone uses emacs and gnus or something similar, email clients could end up mangling the diff unless it was sent as an attachment (which would make reviewing the code and posting an inline response more difficult).
- Leherenn 6y ago
  Both seems non perfect to me. Having to set up one's git config or having to fork a repo seem to be accidental complexity is both cases.
  - u801e 6y ago
    To be fair, setting up one's git config is a one time step. But there is a bit of effort required to keep one's GitHub fork up to date relative to the repository it was forked from.
    - compsciphd 6y ago
      git fetch upstream ; git rebase -i upstream/master isn't that hard.
      - u801e 6y ago
        It depends on whether the histories have diverged and how many conflicts there are. A lot of people aren't very proficient with the use of git and will have problems (e.g., running git pull) and creating a merge commit in their branch or having conflicts they need to resolve. The next time they open a PR using that branch, it will have commits that will clutter the branch.

tomcooks 6y ago

Isn't this "knowing how to use it" come with the usual dose of RTFM and/or trying things? Moreover, I suggest you fork the project and apply your own modifications instead of worrying about a GitHub project administrator to accept your changes

throwaway894345 6y ago

Don’t you just need to open a pull request? Or is there more ceremony that I’m missing?

shred45 6y ago

What you says is true, it can be very difficult to submit ad-hoc patches to large projects. In my experience, however, this has been due to brittle, undocumented automated checks and newbie-hostile maintainers who have built a complex contribution process. I'm not convinced that a different version control system would change this. There are also many projects on GitHub that are very pleasant to work with.