Re: Dealing with an upstream cherry-picked branch

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 15, 2010, 21:30 UTC
Message-ID: <7vocipjmrg.fsf@alter.siamese.dyndns.org>
In-Reply-To: <76718491003142117w4fd10449j51deef27548c4d2e@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 22 quoted lines

> I have the following scenario:
>
>   o---o---Ma---o---o    local-master
>  /       /
> |       | .-b'------d'  upstream-a
> |       |/  :       :
> o---o---a---b---c---d   upstream-master
>
> Local-master branched from upstream-master in distant past.
> upstream-master periodically cuts tentative release branch upstream-a.
> When they do this, that branch point (a) is merged into local-master
> (Ma).
>
> Over time, upstream applies fixes to upstream-a, but does so by
> committing the fixes to upstream-master and then cherry-picking them
> to upstream-a.
>
> The question is how to best integrate the fixes on upstream-a into
> local-master, w/o causing a headache when upstream cuts the next
> tentative release branch, at which point upstrea-master will again
> need to be merged into local-master (and that will also have other
> local development). Here are two options I've considered:

Is it an option not to treat "local-master" as anything but a throw-away integration testing branch?

Presumably upstream-master would be a stable, non-rewinding branch, and when they branch for their next release (i.e. at point 'a' in the picture), you should be able to trust up to that commit. So you would arrange topics on your side to be based on commits before 'a', and never let your people fork from or build directly on local-master.

Rebuild local-master every time you would want to run integration testing with the recent upstream changes, either by starting the throw-away local-master at upstream-master or upstream-a depending on what development phase the upstream is in and what the targetted base for your own release, and merging your topics you intend to ship into it.

                  your topics branch from local-base, which was forked
                  from the last known stable point of the upstream.
                    /       \   \   \
                   /         \   \   \  merge topics for integration testing
                  /           \   \   \
           ...---o local-base  x---x---x local-master (throw-away)
                /             /
    ---o---o---a---b----c----d
                \            upstream-master
                 b'--c'--d'
                         upstream-a

To keep track of the set of topics you know you may want to include in the upcoming release, you could also merge "well cooked" topics into local-base so that your people can build on top of other topics and test them together.

                  your topics branch from (and possibly
                  merge into) local-base
                    / \   \       \   \ 
                   /   \   x---x---x---x local-master (throw-away) 
                  /     \ /   \
 local-base ..---o---o---o   \
                /           /
    ---o---o---a---b---c---d
                \          upstream-master
                 b'--c'--d'  
                         upstream-a

Again, when running integration testing with the recent upstream, you can rebuild your throw-away local-master at the tip of local-base, and merge either upstream-master or upstream-a to make sure your changes work with them.

Individual developers can do the same when testing their own topics in isolation, together with recent upstream, using their own throw-away testing branches that merge their topic and recent upstream.