Re: [PATCHv2] git bisect old/new

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 14, 2012, 17:34 UTC
Message-ID: <7vlijper0e.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAP8UFD2LBKXuey2w_-0Zy9Thi1DWCgekjCL3RULmHWVK5DXCog@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 12 quoted lines

> Peff said:
>
> -------
> Hmm. I think this is not quite as nice, but it is way simpler. It may be
> worth trying for a bit to see how people like it. If they don't, the
> cost of failure is that we have to maintain "old/new" forever, even
> after we implement a yes/no reversible scheme. But maintaining the
> old/new mapping from yes/no would not be any harder than the good/bad
> mapping, which we would need to do anyway.
>
> So it sounds like a reasonable first step.
> -------

The above is a very reasonable stand. But I do not think it leads to the following at all.

> So I'd rather have a file with a generic name like "BISECT_TERMS", but
> it may contain just one line like for example "new/old".

That is forcing an unnecessary complexity, when we do not even know if we need anything more than old/new. We can start simple and the result may be sufficient and in which case we can stop there.

In fact, Peff's advice you quoted is against doing what you just said, which is to do more than we know that we need right now.

If we end up needing arbitrary pair of words, then at that point we may add a mechanism that records the pair of words in use, be they <yes/no>, or <frotz/xyzzy>. And when that happens, <new/old> will continue to be supported for free--there is no extra work to support <new/old> in addition to the work needed to support <good/bad> and <arbitrary1/arbitrary2> that we need to support anyway.