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

[Stephen Kelly]

On Friday 12 March 2010 17:19:31 you wrote:
> 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!

Cool, thanks for the information. 

I'll discuss this with the others here next week, and try to come to some 
understanding and agreement.

All the best,

Steve.

>
> -- Hannes
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-mer
>ges

-- 
Stephen Kelly <stephen at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100312/e4dfacab/attachment.htm