Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Since git-bisect already asks rev-list to find the midpoint (and rev-list > consequently counts the number of commits), rev-list can pass it the > maximal number of commits. > > As a bonus, this avoids an extra call to rev-list. > > Miscalculation noticed by Uwe, implementation suggested by Linus. > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- > > On Wed, 21 Mar 2007, Linus Torvalds wrote: > > > On Wed, 21 Mar 2007, Uwe Kleine-König wrote: > > > > > > Up to now the number printed was calculated assuming that the > > > current revision to test is bad. Given that it's not possible > > > that this always matches the number of suspicious revs if the > > > current one is good, the maximum of both is taken now. > > > > How about adding a new flag to "git-rev-list", to make it count > > both ways? > > Did I understand you correctly? Why not show both, or at least total? This and the earlier optimization patch steps on each others toes, ouch ;-). - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html