Re: [PATCH] bisect: show the maximal number of commits to be tested
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Mar 22, 2007, 02:15 UTC
- Message-ID
- <Pine.LNX.4.63.0703220314440.4045@wbgn013.biozentrum.uni-wuerzburg.de>
- In-Reply-To
- <7vhcsexcc3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 21 Mar 2007, Junio C Hamano wrote:
Show 31 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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@gmx.de> > > --- > > > > 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