4 ms·

> Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this) Technically, no. But how many pro

by tieTYT 12y ago

> Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this) Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead. I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo.

mahyarm 12y ago
You could of added a few steps, like find out what is the right svn branch to commit source code to, because they might only accept patches to the dev branch vs the trunk branch for example.
tankenmate 12y ago
git has tools to accept email patches, it's just most people don't use it. I'd accept email patches as long as they merge in a sane fashion.
perlgeek 12y ago
> Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead. That's more a social issue. How many projects accept patches that go against their submission guidelines? Or coding style guidelines? > I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo. I found that particularly weak. Let's look through them in more detail. 1. Get a copy of the source code 2. Make your change 3. Generate a patch with diff 4. Email it to the mailing list 5. Watch it get ignored Wrong. You can't generate a diff, unless you first made copy of the original sources, or re-download/unpack it. So there's an essential step missing. And often enough, you simply don't have access to the svn repo to do step 1. 1. Fork the repository on GitHub 2. Clone your fork of the source code 3. Make sure you’re on the right branch that upstream expects your patch to be based on, because they totally won’t take patches on master if they expect them on dev or vice-versa. 4. Make a new local branch for your patch 5. Go ahead and make the patch 6. Do a commit 7. Push to a new branch on your GitHub fork 8. Go to the GitHub UI and create a pull request 9. Watch it get ignored 1. is github specific. Gitlab and Bitbucket don't require that 3. applies to SVN projects too. 4. is optional (though highly recommended) But it gets really interesting when you want to do a second, separate patch. Do that svn when you can't commit directly? well, either throw away your first set of changes, or make a complete copy of your whole checkout.
- Animats 12y ago
  "Watch it get ignored" "Submit a patch" is open source's way of telling you to fuck off. The Github business of creating a whole publicly visible fork just to submit a patch is a bit much. I have some obsolete forks on GitHub which I need to kill off so someone doesn't try to use them.
  - Xylakant 12y ago
    Even worse is when people are actually using them because they liked one of your PRs that was never accepted and yell at you when you kill it.
masklinn 12y ago
> Technically, no. But how many projects out there would accept an email patch? Mercurial works with email patches. Not only would they accept it, that's the only way to contribute, sending emails to mercurial-devel. > They'd probably reject it and tell you to issue a Pull Request instead. Obviously you're supposed to use the project's workflow, but the point is nothing prevents you from setting up a patch model with a DVCS. Quite the opposite in fact, both Git and Mercurial have facilities for automatically formatting and sending patchsets, and for applying trucktons of patches. Ref: git am, git format-patch, hg export, hg import and hg email
marssaxman 12y ago
The idea of a "pull request" is a github specific thing, isn't it? Email patches are the normal way of contributing changes in the distributed projects I'm familiar with.
- erikb 12y ago
  Actually the original idea for a pull-request is an email send from your local (but accessible via internet) repo to the original repo maintainers that asks them to fetch changes from your repo and merge them. I think the name of the tool is git pull-request.
  - marssaxman 12y ago
    Ah, it's git-request-pull. Thanks, I'd never heard of it.
erikb 12y ago
I wouldn't be surprised if there are still more repos with >100 maintainers who mostly receive mail patches. Just because you haven't grown up learning them doesn't mean they are not bigger than all you know, right?
lmm 12y ago
It's a fake comparison. It only looks like fewer steps because he's not counting how many steps it takes to send an email with an attached file. Not to mention joining a mailing list.
qznc 12y ago
There are also projects that reject pull requests and require an email patch. Different projects, different work flows. I'm agree with the author that the Github model of "always fork the repo public" is stupid. Why not simply push to the official project repo and (for unauthorized people) let it show up as a "pull request"?

by tieTYT 12y ago

mahyarm 12y ago

You could of added a few steps, like find out what is the right svn branch to commit source code to, because they might only accept patches to the dev branch vs the trunk branch for example.

tankenmate 12y ago

git has tools to accept email patches, it's just most people don't use it. I'd accept email patches as long as they merge in a sane fashion.

perlgeek 12y ago

> Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead. That's more a social issue. How many projects accept patches that go against their submission guidelines? Or coding style guidelines? > I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo. I found that particularly weak. Let's look through them in more detail. 1. Get a copy of the source code 2. Make your change 3. Generate a patch with diff 4. Email it to the mailing list 5. Watch it get ignored Wrong. You can't generate a diff, unless you first made copy of the original sources, or re-download/unpack it. So there's an essential step missing. And often enough, you simply don't have access to the svn repo to do step 1. 1. Fork the repository on GitHub 2. Clone your fork of the source code 3. Make sure you’re on the right branch that upstream expects your patch to be based on, because they totally won’t take patches on master if they expect them on dev or vice-versa. 4. Make a new local branch for your patch 5. Go ahead and make the patch 6. Do a commit 7. Push to a new branch on your GitHub fork 8. Go to the GitHub UI and create a pull request 9. Watch it get ignored 1. is github specific. Gitlab and Bitbucket don't require that 3. applies to SVN projects too. 4. is optional (though highly recommended) But it gets really interesting when you want to do a second, separate patch. Do that svn when you can't commit directly? well, either throw away your first set of changes, or make a complete copy of your whole checkout.

Animats 12y ago
"Watch it get ignored" "Submit a patch" is open source's way of telling you to fuck off. The Github business of creating a whole publicly visible fork just to submit a patch is a bit much. I have some obsolete forks on GitHub which I need to kill off so someone doesn't try to use them.
- Xylakant 12y ago
  Even worse is when people are actually using them because they liked one of your PRs that was never accepted and yell at you when you kill it.

masklinn 12y ago

> Technically, no. But how many projects out there would accept an email patch? Mercurial works with email patches. Not only would they accept it, that's the only way to contribute, sending emails to mercurial-devel. > They'd probably reject it and tell you to issue a Pull Request instead. Obviously you're supposed to use the project's workflow, but the point is nothing prevents you from setting up a patch model with a DVCS. Quite the opposite in fact, both Git and Mercurial have facilities for automatically formatting and sending patchsets, and for applying trucktons of patches. Ref: git am, git format-patch, hg export, hg import and hg email

marssaxman 12y ago

The idea of a "pull request" is a github specific thing, isn't it? Email patches are the normal way of contributing changes in the distributed projects I'm familiar with.

erikb 12y ago
Actually the original idea for a pull-request is an email send from your local (but accessible via internet) repo to the original repo maintainers that asks them to fetch changes from your repo and merge them. I think the name of the tool is git pull-request.
- marssaxman 12y ago
  Ah, it's git-request-pull. Thanks, I'd never heard of it.

erikb 12y ago

I wouldn't be surprised if there are still more repos with >100 maintainers who mostly receive mail patches. Just because you haven't grown up learning them doesn't mean they are not bigger than all you know, right?

lmm 12y ago

It's a fake comparison. It only looks like fewer steps because he's not counting how many steps it takes to send an email with an attached file. Not to mention joining a mailing list.

qznc 12y ago

There are also projects that reject pull requests and require an email patch. Different projects, different work flows. I'm agree with the author that the Github model of "always fork the repo public" is stupid. Why not simply push to the official project repo and (for unauthorized people) let it show up as a "pull request"?