Re: [PATCHv2] git bisect old/new

[Phil Hord <phil.hord@gmail.com>]

On Thu, Jun 14, 2012 at 1:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > 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.

Except that most of the work to support <arbitrary1/arbitrary2> is
already being done in this patch to add <new/old>, but it will need
re-doing or un-doing to move to arbitrary terms.  Supporting arbitrary
terms today would save work (the re-doing and the un-doring), if we
went that way in the future.

But perhaps we won't.

Phil