I’m trying to find best practises on this:
- I take an existing project written by someone else and fork it
- let’s say I plan ahead and make a branch before I edit the project locally
- I make setofchanges#1 in branch1
- I send pull request
- upstream owner does not merge my change, because busy. It may get reviewed/merged months later, or never
- I want to continue to work on that project, and ideally my changes to be in my master branch, because that’s what users see by default when they look at my github fork.
This is where I’m a bit stuck.
If I stop waiting for upstream, merge my change into my master, and then write setofchanges#2
Now I’m a bit stuck for sending them as a separate pull request to upstream because github obviously sends a diff of both setofchanges#1 + setofchanges#2
If instead I create branch#2 on top of branch#1, I can use github to show setofchanges#2 because it can show a diff between 2 branches, but I don’t think I can send a diff between 2 of my branches as a PR to upstream.
The only clean option is to have branch#1 and branch#2 based on master, both have their own separate diffs, and never merge them in my master
until upstream merges my stuff, which could be never.
This sucks for people using my fork since my upstream doens’t have the up to date code, and unless I maintain a prod branch where I manually cherry pick the changes from all my branches, I also don’t have an up to date branch I can use.
If I could send a diff between tags or branches, that would work better, but I don’t think I can in github (with raw git you can of course).
So for now, I’ve created a MarcFork organization in my github, which I use to re-fork the upstream project so that that master is the upstream master (and not my master that is ahead), and hold the change I’m trying to send for review.
If needed I have a MarcFork2 for a 2nd change in parallel.
This seems iffy though. Is there any better solution with github?
Thanks,
Marc