<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">On Friday 12 March 2010 17:19:31 you wrote:<br>
> The summary you gave is to the point.<br>
><br>
> To have an 'Enterprise5-features' branch as described is a valid workflow<br>
> - it's just not my personal favorite. This reply is just FYI, and we can<br>
> move on.<br>
><br>
> Stephen Kelly schrieb:<br>
> > On Friday 12 March 2010 15:34:31 you wrote:<br>
> >> What's bad with merge commits?<br>
> ><br>
> > My second-hand knowledge is that it makes git-bisect more painful. I<br>
> > don't recall exactly why right now. Something about having to traverse<br>
> > both merged branches manually when a merge commit is hit.<br>
><br>
> You mean this situation: You have a number of feature branches merged into<br>
> Enterpise5-features; the latter was itself merged into KDE master, then<br>
> development proceded on master. Like so:<br>
><br>
> A B C D <-- feature branches (they begin far before X)<br>
> \ \ \ \<br>
> --p--q--r--s <-- Enterpise5-features<br>
> \<br>
> --o--o--X--Y--N--o <-- KDE master<br>
><br>
> Now a bug surfaces, and git-bisect says that N is the commit that<br>
> introduced the bug. This is actually an argument *against* using an<br>
> Enterpise5-features branch, and I tell you why.<br>
><br>
> The sketched situation can happen if, for example, commit X changed the<br>
> contract of a function Foo() and B introduced a new call of Foo(). Let's<br>
> further assume that the problem did not show up in the merge commit N<br>
> because the change was only in the contract, not in the API of Foo(), and<br>
> the compiler didn't notice it.<br>
><br>
> Nevertheless, both predecessors of N are good (all callers of Foo() in Y<br>
> have been updated to use the new contract; all callers of Foo() in s,<br>
> including the new call site of B, use the old contract).<br>
><br>
> This situation is not unlikely in your setup because KDE master can be far<br>
> ahead of Enterpise5-features (which is based on an old, stable version of<br>
> KDE, and so are all the topics that it merged) and there is a lot of room<br>
> for contracts to be changed along KDE master.<br>
><br>
> How do you find out that the conflict is between B and X? You rebase the<br>
> shorter arm onto the longer; this gives a new set of commits, and you<br>
> bisect those. How many new commits do you get here? All of A,B,C,D.<br>
><br>
> OTOH, if you merged the topics individually:<br>
><br>
> A B C D <-- feature branches<br>
> \ \ \ \<br>
> --o--o--X--Y--P--Q--R--S--o <-- KDE master<br>
><br>
> git-bisect would have pointed you to commit Q. You immediately know that A<br>
> is good, and C and D are not to blame. This leaves you with B only!<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Cool, thanks for the information. <br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>I'll discuss this with the others here next week, and try to come to some understanding and agreement.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>All the best,<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>Steve.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>><br>
> -- Hannes<br>
><br>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#bisect-mer<br>
>ges<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>-- <br>
Stephen Kelly <stephen@kdab.com> | Software Engineer<br>
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company<br>
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090<br>
KDAB - Qt Experts - Platform-Independent Software Solutions</p></body></html>