Managing topic branches

[Junio C Hamano <junkio@cox.net>]

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.