Managing topic branches

Managing topic branches

[Junio C Hamano]

I adopted Tony's excellent "topic branches" workflow to manage
the topics cooking in separate branches.  The flow goes like
this:

 - The change to the topic are made as new commits on top of
   the topic branch.  My naming convention for topic branches
   are two letters directory under .git/refs/heads/ and short
   word.  E.g. np/delta for Nico's finer-grained delta work,
   ml/cvsserver for Martin's git-cvsserver.

 - To test topics myself and publish the bleeding edge to
   others, updated topic branches are merged into "next".  If I
   have some changes to "master", the tip of it is also
   merged into "next", so that people following "next" will not
   miss out trivial fixes directly made to "master".

 - Once a topic is fully cooked, it is merged into "master".  I
   delete the topic branch in my private repository (its tip is
   already merged into "master" and also it was merged into
   "next" long time ago).

This worked reasonably well, and I can see what are still not in
"master" but brewing in "next" with two ways:

 - "git log master..next".  This is the orthodox way to view
   list of commits that are in next but still not in next.
   Giving --no-merges option would help cutting down the
   cluttering.

 - "git show-branch --topics master 'heads/??/*'". (note: ??/*
   is literally given to show-branch to let it glob).

However, the former started to break down recently, due to two
reasons.

1. np/delta turned out to be unsatisfactory, and I had reverts
   and re-reverts in the topic branch.  Eventually Nico and I
   decided to throw away the last three commits after merging
   the earlier bits into "master".

        (other topic brances merged into next)
           \   \       \    \      \   \
        o---o---o---o---o---o---o---o---o next
       /           /           /
      o---o---x---x---x---x---x np/delta
     /     \ <-- earlier parts merged
    o---o---o---o---o master

Some commits on "np/delta" merged into "next" are reverts and
the tip of "next" now do not have unwanted bits from the
finer-grained delta experiments.  I have dropped np/delta topic
branch, so "show-branch --topics" does not bother me with these
commits marked with 'x' anymore, but "git log master..next" will
keep showing them


2. "ml/cvsserver" was initially based on then-current "next"
   tip, because it depended on something else that was only
   present in "next", but by the time I pulled it from Martin,
   the pieces it depended on have already graduated to "master".

Since I wanted to have cvsserver in the "master" sooner than
everything else that were in "next" when Martin prepared these
commits, I ended up doing this:

Here is what the ancestry graph looked like when I received
cvsserver stuff:

                        a---b---c ml/cvsserver
                       /
          o---o---o---o next
         /   /   /             A: another topic ml/cvsserver
        /   A   B*                depended on
       /     \                 B*: many other "unready" topics
      o---o---o---o master

So I cherry-picked them on to "master", and merged both
"ml/cvsserver" and "master" into "next":

                        a---b---c ml/cvsserver
                       /         \ <-- questionable octopus leg
          o---o---o---o-----------* next
         /   /   /               /  
        /   o   o               /  
       /     \                 /
      o---o---o---o---a'--b'--c' master

I could have done without the "questionable octopus leg", but I
did so that when Martin pulled my "next" into his cvsserver
branch, he does not have to do the real merges [*1*].  But now
commits a---b---c comes back to haunt me whenever I do "git log
master..next".

The moral of the story is not to try to be nice to others
without thinking about its concequences ;-).  I should have just
done without the "questionable octopus leg", and asked Martin to
discard and rebase his tip of the development to my "next" after
this merge.


Anyhow, what I ended up doing to make "log master..next" usable
again was to cauterize the tips of unwanted topic branches
merged into next by merging them into "master" branch using
"ours" strategy:

	$ git checkout master
	$ git merge -s ours "excuse for this" HEAD ml/cvsserver np/delta

Luckily, I have merged up all the B*'s from "next" to "master",
so this was possible, but otherwise until I either merge them to
"master" or decide to drop forever I needed to keep a---b---c
around in "log master..next" output for a loooong time X-<.


[Footnote]

*1* I briefly thought about doing this instead, but this is a
wrong thing to do:

                        a---b---c ml/cvsserver
                       /         \       
          o---o---o---o-------------------* next
         /   /   /                 \     /
        /   A   B*                  \   / 
       /     \                       \ /
      o---o---o---o-------------------* master
                   \                 /
                    a'------b'------c'
                     (cherry picked)

At this point, master would claim to have merged B* but actually
it has not.

Re: Managing topic branches

[Martin Langhoff]

On 3/5/06, Junio C Hamano <junkio@cox.net> wrote:
> I could have done without the "questionable octopus leg", but I
> did so that when Martin pulled my "next" into his cvsserver
...
> The moral of the story is not to try to be nice to others
> without thinking about its concequences ;-).  I should have just
> done without the "questionable octopus leg", and asked Martin to
> discard and rebase his tip of the development to my "next" after
> this merge.

No good deed goes unpunished as they say ;-)

In any case, this was perhaps based on a misunderstanding/error on my
side. To start off, I didn't understand how you were managing next.

I assumed next would be a 'rewind often' branch, a volatile thing that
I shouldn't build upon. But as I was in the awkward situation of
depending on something in next, I had to, and didn't think of the
consequences. As the branch I published for you to pull was based on
next, which meant you couldn't merge my stuff into master.

So it was a thinko on my side. I just though -- damn, I'll have to
work based on next, with the downside of having to be alert for
rewinds. Didn't think of the implications for you.

It's sorted now, but at great pains for you. I guess all I can suggest
is to put something in the name of the branch that means both "rewinds
often" and "don't base real work on this". I guess that would be
anything but master/maint, but the rules around pu are sometimes
tricky too (rewinds often, but some people have no option but to build
against it, unless you are treating it same as you treat next).

Anyway -- sorry to have caused so much trouble. My work "pending" is
at the most a patch or two, easy to extract and reapply. If something
like this comes up again, just do whatever is easiest and tell me to
rewind/rebase/cherrypick at my end.

cheers,


martin

Re: Managing topic branches

[Junio C Hamano]

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

> In any case, this was perhaps based on a misunderstanding/error on my
> side. To start off, I didn't understand how you were managing next.

No nononononono nooooo.

If I sounded like you were the guilty party I apologize.  I did
not mean it that way.

It was my mistake.  I encouraged people to experiment and build
upon "next".  It was just the way I pulled the stuff in was bad.