Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
How should open source forks, with a mix of upstreamable and non-upstreamable commits, be maintained?
I have a few different projects that rely on open source technology that I wish to make modifications to (say, to add key features for business or personal use) that will vary between upstreamable (the upstream fork would be interested in the feature) and non-upstreamable (the upstream repository has vocally been against the idea, but I still need it or want it for my own projects.)
Ideally, I would like to be able to keep my branch up to date with the latest changes. Currently, I maintain a branch (named akin to personal/version_num) which I rebase against upstream's version_num tag. This works fine, but it suffers some issues and becomes a bit of a maintenance burden. Specifically, it's hard to account for merge requests that have already been "factored in" to upstream on rebase. Additionally, every version update feels like a partial history rewrite (as rebasing causes all of our internal commits to come to the top of the log, while all upstream commits are below even if they were authored "after" the commits above.)
What is the ideal way to have this process mostly automated (where conflict-free rebasing is possible)? If you are familiar with other companies that have to maintain branches in a similar manner, do you have any advice for ways to organize forks that might have commits that are both upstream candidates and also non-upstreamable (but still open source)?
1 answer
The ideal way is to separate the upstreamable and non-upstreamable changes.
For example you could maintain two branches: public and private. All upstreamable changes are cherry picked to public and this is what you send back to the upstream. All your non-upstreamable changes would be in private.
0 comment threads
0 comment threads