4 ms·

As someone who has dealt with this, it's not as big a deal as you might think. Most future forks are based on older forks, so all the person at the end of the l

As someone who has dealt with this, it's not as big a deal as you might think. Most future forks are based on older forks, so all the person at the end of the line has to do is fast forward onto the end of the branch. One FF merge, push, end of story. When you have bifurcations, you can do an octopus merge - git is really good at resolving these things. Very little human effort is needed except where multiple revisions change the exact same line in different ways. In addition to this, most patches that people submit are quite small. Even if you have 200 people submitting patches, the odds are that most of them fall into two categories: people fixing the same bug, and people working on completely different sections of code. Neither is a substantial problem to merge. I think I can count on one hand the number of times I had to do any nontrivial merge work on patches from contributors... And you're pretty delighted to do it - it means they fixed something that really matters.

adamrg 15y ago
(as the author of the original post) In theory, yes. And I never used to worry about this. But over time, in practice, it's been a bigger problem than I think you're giving credit to. e.g. ... "Even if you have 200 people submitting patches, the odds are that most of them fall into two categories: people fixing the same bug, and people working on completely different sections of code. Neither is a substantial problem to merge." IME ... in practice, this is a HUGE problem. Because every one of those developers fixes the bug in a slightly different way. The longer time goes on without the original Author fixing it, the worse it gets. And the cost to them - or anyone! - of sifting through the "100 variations on bug fix #123" becomes greater and greater. Usually, you want to cherrypick individual lines and characters from 5-10 of the best "solutions" to the bug. If you'd avoided the "100 alternative fixes", then those "improved" solutions would have been built on the "basic" solutions - and merging would be easy. But because you've got to this massively-forked scenario, all of the patches have been written independently and incompatibly.
- moe 15y ago
  But because you've got to this massively-forked scenario That may be true for the 0,0001% of projects that have so many contributors that they need dedicated release managers and such anyway. The remaining 99,9999% projects are just grateful for github making contribution so easy that they're now receiving patches at all.
- jaggederest 15y ago
  Not in practice. In practice, people base their work on the most recent work. You get maybe 4-5 versions of any given bug fix, max, proportionally to how easy it is to fix.

adamrg 15y ago

(as the author of the original post) In theory, yes. And I never used to worry about this. But over time, in practice, it's been a bigger problem than I think you're giving credit to. e.g. ... "Even if you have 200 people submitting patches, the odds are that most of them fall into two categories: people fixing the same bug, and people working on completely different sections of code. Neither is a substantial problem to merge." IME ... in practice, this is a HUGE problem. Because every one of those developers fixes the bug in a slightly different way. The longer time goes on without the original Author fixing it, the worse it gets. And the cost to them - or anyone! - of sifting through the "100 variations on bug fix #123" becomes greater and greater. Usually, you want to cherrypick individual lines and characters from 5-10 of the best "solutions" to the bug. If you'd avoided the "100 alternative fixes", then those "improved" solutions would have been built on the "basic" solutions - and merging would be easy. But because you've got to this massively-forked scenario, all of the patches have been written independently and incompatibly.

moe 15y ago
But because you've got to this massively-forked scenario That may be true for the 0,0001% of projects that have so many contributors that they need dedicated release managers and such anyway. The remaining 99,9999% projects are just grateful for github making contribution so easy that they're now receiving patches at all.
jaggederest 15y ago
Not in practice. In practice, people base their work on the most recent work. You get maybe 4-5 versions of any given bug fix, max, proportionally to how easy it is to fix.