Re: Dealing with an upstream cherry-picked branch

> 0a) Have them do their bugfixes directly in the upstream-a branch,
> then merge sometimes from upstream-a to upstream-master.  Then when
> they cut upstream-b from upstream-master, it should be an easy merge
> for you (since they've already resolved any conflicts between
> upstream-a and upstream-master as they arose over time).
>
> 0b) If they really need to do their bugfixes on upstream-master and
> then cherry-pick them back to upstream-a, have them merge upstream-a
> into upstream-master sometimes *anyway*, resolving any (probably
> trivial) conflicts as they arise.  I say the conflicts should be
> trivial because they're just cherry-picks anyway, so git will mostly
> notice they're identical and ignore them.  This is easy to do a little
> at a time, but gets more complicated if you wait a long time between
> merges.
>
> 0c) Like 0b), only use 'git merge -s ours' to merge from upstream-a
> into upstream-master.  This assumes that upstream-a *never* has a fix
> other than one that is already in upstream-master, so that all
> conflicts necessarily resolve to exactly what's already in
> upstream-master.  This makes it easier for downstream people to merge
> but doesn't actually cost any extra effort.

> As for your original suggestions:
>
>> 1) Create a local-a integration branch, merged from upstream-a and
>> local-master. Keep this branch up-to-date by periodically merging
>> local-master and upstream-a:
>
> This will be inconvenient since local-master won't actually be useful;
> if upstream-a contains a critical patch, you won't be able to test
> your changes in local-master until you merge them into local-a.  Thus
> the history of local-master, while "clean", will actually be
> meaningless.

>> 2) Periodically merge upstream-a into local-master:
>> [...]
>> Then when it is next time to merge upstream-master into local-master either:
>>
>> (a) Backout the upstream-a merges to local-master by reverting the
>> merge commits which introduced them to local-master, then merge
>> upstream-master.
>
> Don't try to revert merge commits; that generally ends in disaster,
> both in terms of your tree's correctness and your ability to
> accurately retrace the history of your branch.  Possibly you can make
> it work, but I don't know anybody who has.  Even if you can, you'll
> still hate yourself in the morning.

>> (b) Just merge upstream-master and carefully deal with all the
>> conflicts. I think this will necessarily be an evil merge.
>
> This is probably not as hard as it sounds, particularly if upstream-a
> is *purely* a subset (in terms of cherry-picks, not in terms of
> history) of upstream-master.  I'd recommend something like this (just
> once when it's time to move to a new release branch):
>
>       git checkout -b mergey upstream-master
>       # take the history of upstream-a but not the content:
>       git merge -s ours upstream-a
>       # assuming local-master is your branch based on upstream-a:
>       git checkout -b local-b local-master
>       # merge the changes from upstream-a to upstream-master into local-b:
>       git merge mergey
>
>> (c) Create a new branch at point Ma and cherry-pick only the local
>> commits from local-master past point Ma. This essentially gives me the
>> clean local-master I would've had if I'd been doing (1) all along.
>
> This will work, but the short form for exactly the same operation is:
>
>        git checkout -b local-b local-master
>        git rebase --onto upstream-master upstream-a

> It will result in a cleaner history, and importantly, one that
> upstream would probably be willing to merge someday.  You won't have
> any extra cherry-picked commits confusingly merged into your history
> with the original commits.
>
> The disadvantage is that each of your branches will have a disjoint
> history: there will be no branch showing how you got from local-a to
> local-b, since they're actually two totally different things.  In git,
> the ideal case is that if you look at the history of HEAD, you can see
> the *entire* evolution of the product, and using a different
> merge-base for each branch gets in the way of that.
>
> The best option above, IMHO, is my proposed option 0.  But any of the
> others will work.