3 ms·

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.

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.