On Mon, Mar 15, 2010 at 5:30 PM, Junio C Hamano [off-list ref] wrote:
Jay Soffian [off-list ref] writes:
quoted
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.