In <[email protected]>, Thiago Macieira wrote: >On Wednesday, 9 de February de 2011 03:41:32 Boyd Stephen Smith Jr. wrote: >> Having the correct branch points, even for branches that are one or two >> commits long, can be useful both for automated tools like git bisect and >> for users that may want to use "just enough development code" for a >> critical (to them) feature their stable software is missing. In both >> cases, it is only an incremental improvement, true. > >Or a detriment. Git bisect doesn't perform as efficiently in the presence of >merges, since it can't find a middle point to bisect at.
Um, sort of. A-*---*-B \ / *-*-* A = Good B = Bad Yes, no middle point, and if the commits were linear, then there would be exactly one to choose. However, there are other cases where a non-linear history allows git bisect to test fewer commits, instead of more. (Basically, almost any time a merge commit and the merge-base of all it's parents are either good or bad.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. [email protected] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
