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 <[email protected]> | 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
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
