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.