Merging previously contributed upstream changes

Question

Given I am in a team maintaining a long term fork of a repo, where I want to diverge but still contribute some of my changes upstream, I am not sure how to deal with this situation:

• I make a commit to my fork that I subsequently want to contribute upstream
• I PR the upstream repo
• I have no control over how the upstream owner merges, and they choose to rebase my changes when merging
• I later try to update my fork with the latest changes from upstream (master -> master), and my previously contributed commit is duplicated in the logs because of the different hashes. I cannot rebase like I would with a personal branch.

Answer 1

You have no good choices here.

The fact is that they have copied your commits to new commits. There are now two copies. If you wish to continue using their repository, you either drop your commits—i.e., rebase and suffer with the hash changes—or you keep both. Therefore, there are only three options in total:

1. Don't share repositories (don't pick up their commits anymore): suffer with (whatever degree of) disengagement.
2. Suffer with duplicate commits.
3. Suffer with your own rebases to strip duplicate commits.

Personally, I'd probably go with some combination of 2 and 3: there's really not that much suffering with option 2 after all, and if you coordinate with others who use your repository, you can minimize the pain of option 3 as well.

That is, you and anyone else using your fork—your repository that's loosely, rather than tightly, coupled to the ultimate upstream repository; let's call your fork F and the upstream fork U—for anyone using F, you all agree that some branch name(s) get rebased on U based on time, or number of commits, or whatever other criteria. You all use other branches to get work done, and then copy that work to a rebased-on-slaved-with-U branch before sending it (as a pull request or whatever) to the folks who work with U. You also copy your work to the "latest U-based branch(es)" as needed for whatever kind of progress you want to make.

This way, your fork F is under your (plural, "you" being your own group) shared control, semi-independent of U, but some parts of F are resynchronized with U on some sort of regular basis. (Different parts can have different schedules: whatever makes the most sense for you.) You (the group) choose what, when, and how to resynchronize.