Managing topic branches

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.

On 3/5/06, Junio C Hamano <junkio@cox.net> wrote:

...

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

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

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.