Re: Dealing with an upstream cherry-picked branch

[Jay Soffian <jaysoffian@gmail.com>]

On Mon, Mar 15, 2010 at 5:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> 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?

Our development is currently very fast paced among a smallish group of
developers, and so far the developers really prefer to all work on the
same branch (i.e, not use topic branches). So they are constantly
pushing their changes to local-master. However, I don't think that
precludes an integration branch if I just squint at your picture
below...

> 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

By squinting, I can pretend that all the developers pushes to
local-master are mini "well cooked" topics. And I can call my
throw-away branch something like, oh say, "next". So I will have this
picture:

                 developer pushes
                         / \
                    -----   \
                   /   / \   \
local-master ..---o---o---o---o ...    local-master
                 / \       \   \
                /   `---o---o---o---o  next
               /       /           /
       ---o---a---b---c---d---e---f upstream-master
               \
                b'--c'--d' upstream-a


The merges from upstream-master to next will happen at well-defined
times by an integration manager. The merges from local-master to next
will be done by developers themselves to give them exposure to what is
happening upstream-master.

But, it's not clear how that helps me with upstream-a, unless I also
have a "local-a" branch:

local-master ..---o---o---o---o ...    local-master
                 / \       \   \
                /   `---o---o---o---o  local-a
               /       /           /
       ---o---a---b'--c'----------d'   upstream-a


But now I'm asking for developers to:

a) commit changes to local-master
b) merge to next
c) merge to local-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.

I think I'm not clear how it helps to make the integration branch
throw-away. Unless you mean something like git pu?

Let's assume I want the developers to have the benefit of seeing
what's in upstream-a and upstream-master. Let's also assume the merges
from upstream-master are typically non-trivial. If "next" in my
picture above is something each developer creates themselves, then
there is no way to share merge resolutions. That would be painful.

j.