Jay Soffian <jaysoffian@xxxxxxxxx> 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?
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html