[Kde-scm-interest] KDE PIM branches workflow with git

[Johannes Sixt]

The summary you gave is to the point.

To have an 'Enterprise5-features' branch as described is a valid workflow
- it's just not my personal favorite. This reply is just FYI, and we can
move on.

Stephen Kelly schrieb:
>  On Friday 12 March 2010 15:34:31 you wrote:
>> What's bad with merge commits?
> 
> My second-hand knowledge is that it makes git-bisect more painful. I
> don't recall exactly why right now. Something about having to traverse
> both merged branches manually when a merge commit is hit.

You mean this situation: You have a number of feature branches merged into
Enterpise5-features; the latter was itself merged into KDE master, then
development proceded on master. Like so:

  A  B  C  D          <-- feature branches (they begin far before X)
   \  \  \  \
  --p--q--r--s        <-- Enterpise5-features
              \
 --o--o--X--Y--N--o   <-- KDE master

Now a bug surfaces, and git-bisect says that N is the commit that
introduced the bug. This is actually an argument *against* using an
Enterpise5-features branch, and I tell you why.

The sketched situation can happen if, for example, commit X changed the
contract of a function Foo() and B introduced a new call of Foo(). Let's
further assume that the problem did not show up in the merge commit N
because the change was only in the contract, not in the API of Foo(), and
the compiler didn't notice it.

Nevertheless, both predecessors of N are good (all callers of Foo() in Y
have been updated to use the new contract; all callers of Foo() in s,
including the new call site of B, use the old contract).

This situation is not unlikely in your setup because KDE master can be far
ahead of Enterpise5-features (which is based on an old, stable version of
KDE, and so are all the topics that it merged) and there is a lot of room
for contracts to be changed along KDE master.

How do you find out that the conflict is between B and X? You rebase the
shorter arm onto the longer; this gives a new set of commits, and you
bisect those. How many new commits do you get here? All of A,B,C,D.

OTOH, if you merged the topics individually:

             A  B  C  D        <-- feature branches
              \  \  \  \
 --o--o--X--Y--P--Q--R--S--o   <-- KDE master

git-bisect would have pointed you to commit Q. You immediately know that A
is good, and C and D are not to blame. This leaves you with B only!

-- Hannes

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-merges
-- 
"Atomic objects are neither active nor radioactive." --
Doc.No N3035 (Working Draft, Standard for Programming Language C++)