4 ms·

Forking (as opposed to branching which at least has community acknowledgement) should be taken as a last resort. Without the support from upstream, just _synci

Forking (as opposed to branching which at least has community acknowledgement) should be taken as a last resort. Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork.

znpy 2y ago
> Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. This happens if you don't fork often, post your changes once in a very long time, and don't rebase your work very often. If you rebase often enough you shouldn't have the mergeability problem. > It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork. The alternative is letting people greenlight you to even go and do a proof of concept. It smells like bureaucracy to me. Having a fork and a working proof of concept can back your argument about feature development. The implementation is just a detail and can be adjusted or reworked as necessary. Otherwise you risk your ideas getting stalled (or worse, completely rejected) by people that don't even fully understand what you're talking about.