Re: [PATCH 2/2] git.c: binary-search builtin commands
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Feb 16, 2011, 03:46 UTC
- Message-ID
- <AANLkTi=xnM+ejrDMCNBr21BtnqwD5TXXoLZbE7uPMhR0@mail.gmail.com>
- In-Reply-To
- <7v4o85njjz.fsf@alter.siamese.dyndns.org>
2011/2/16 Junio C Hamano <gitster@pobox.com>:
Show 28 quoted lines
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: >> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> >> --- >> 2011/2/15 Junio C Hamano <gitster@pobox.com>: >> > I did this myself the other day, as I think it simply is a good project >> > hygiene. If this were 1/2 of a series followed by 2/2 that runs binary >> > search in the table, that would make it make more sense ;-) >> >> I did think the array was binary-searched and nearly claimed "git-stage >> won't work because it's in wrong order". > > Heh, that "binary search" was a tongue-in-cheek comment. I am sorry that > you took it too seriously. > >> This patch won't give any performance gain, but it would force >> people to keep the array in order :-) > > That is exactly why I discarded what I did the other day. Without an > active mechanism to force the orderedness, such a change simply introduces > a downside of letting a mistake go unnoticed, without any real upside (as > you measured and saw no performance gain). > > A better project hygine is a good thing to aim for, and I would imagine > that you could add "--verify-builtin-command-table" as an unadvertised > option to "git" wrapper, and make t/t0000-basic.sh call it to minimize the > downside risk. But without such an active measure to prevent mistakes, we > would be relying on somebody getting caught on a ticking bomb and > reporting it, which is not a good tradeoff between risk and reward.
Ah, OK. Just drop this patch. I don't think doing binary search gains us much anyway.
-- Duy