Ferret7446
8 hours ago
This doesn't seem to be about forking, but rather contributing upstream using a GitHub-like model.
If you're actually forked, you shouldn't be rebasing.
diggan
4 hours ago
> This doesn't seem to be about forking, but rather contributing upstream using a GitHub-like model.
Probably useful to distinguish between the concept of "forking" where you basically take the existing project, duplicate it, then start working on your own independently, and the action of "forking" in the GitHub UI that just duplicates a repository.
The latter is commonly used for contributing upstream, while the former would be when you don't want to contribute and want something independent.
noirscape
3 hours ago
It depends a bit on the nature of a fork (not all forks are made equal!); here's my experience with forks:
* Feature forks - exists because upstream doesn't want to merge a certain (set of) features for whatever reason. These aren't necessarily hostile forks, it's just that upstream didn't use a forkable/modifiable license to accept third party patches. There's a lot of these sorts of "stacks" (a lot of them written in Ruby, which in my experience has very bad separation of the device it's running on and the source code), where portability outside of upstreams deployment just isn't a concern. For these, frequent rebases are fine - the feature forks only has a single developer, is unlikely to need many external contributions and can often just subsist by mainting a couple of .patch/.diff files for each major release (depending on how much the forker cares). This type of fork isn't really seeking to be its own project. It's also the type that the post is talking about, where you can effectively maintain your patches as single rebases, which saves some mental overhead. (Icecat is an example of this sort of fork, although for rather silly reasons.)
* "Soft" hostile forks. Upstream isn't bad or dangerous, but is notoriously unresponsive on issues they should be responsive on. The fork has it's own governance, but it's very much a skeleton and merging upstream code is a major priority to keep the project going. These projects tend to either fizzle out, fall back in-line with upstream or become a true hostile fork.
* True Hostile Forks: Upstream has lost its marbles. They're unreliable and can't be build further on. Worst case scenario; the fork is downstream only in the sense that the upstream shouldn't be used anymore. Here, merging upstream code is either to be avoided or should be checked the same as a third party contribution.