Git makes me redo a big merge the next time I try to merge something

Question

There are 2 branches of an opensource project on github: cat and cheetah

Cheetah has a lot of differences vs cat, but all the cat changes are merged into cheetah, however not the other way around.

If I do a big commit[s] on cat in my local-cat branch, and wait for them to be merged first; and then I then make a merge commit for cat => local-cheetah => cheetah; it works fine.

But it could be days before the admin merges my local-cat code, so I need to be able to make my changes in local-cat, and the branch cheetah into local-cheetah, and make the merge commit from local-cat => local-cheetah, publish both PRs, and have it work.

So 2 PRs, one from local-cat => cat

And one with local-cat => local-cheetah => cheetah

(Worth noting the maintainer does a squash for all commits to cat, but did a merge commit for the local-cheetah => cheetah PR.)

The problem when doing this is when I do it as just described, their last common ancestor is still the commit before I did anything, so the next time we have to do a merge from cat => cheetah, even if it's tiny, someone has to redo all the merge conflicts from my big merge.

How can I prevent this from happening without waiting for my local-cat PR to commit to cat and then merging cat => local-cheetah?

Answer 1

The problem when doing this is when I do it as just described, their last common ancestor is still the commit before I did anything

That is what rebase exists:

• rebase local-cheetah on top of origin/local-cheetah
• then make your second PR local-cheetah => cheetah: any potential conflict would have been resolve first locally during the rebase.

If you fond yourself resolving conflicts twice, don't forget to use rerere.