Re: [PATCH] bisect: show the maximal number of commits to be tested

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, 21 Mar 2007, Junio C Hamano wrote:

> 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 ;-).

Yes... on both accounts. I'll let your patches settle first, and resubmit.

Ciao,
Dscho

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]