← Back to context

Comment by magicalhippo

5 years ago

Especially weird seeing as Github has made forking a very smooth way to work with a project. You fork it, make the changes you want, and then make the changes available upstream.

If upstream vanishes, your fork is still around.

If upstream doesn't want to merge, people can use your fork instead. And, if your changes are that much better, eventually make it the de-facto standard version of the project.

Yes, and it happens all the time in other projects. There's always "so-and-so's fork that implements feature X and changes Y", and it's awesome that that's a possibility since it means no project is held hostage by its maintainer, and that differences in priorities don't mean the code can't be useful for a range of use cases.

The commits you do in a fork are not visible in your GitHub commit calender until you do a PR and they are merged. For some people this is important so a "forked" project won't have many commits with merging back to master.

  • lol what?

    They won't contribute or work on something unless it touches their commit calendar?

    I'm kind of…

    I guess that's not really a use case I'm concerned with, contribution-wise.

    But who knows! Maybe most of open source work is done for personal vanity.

  • You can merge your commits into a separate branch and designate it as the "default" branch for your repository.