Re: [PATCHv2] git bisect old/new

On Thu, Jun 14, 2012 at 1:34 PM, Junio C Hamano [off-list ref] wrote:

Christian Couder [off-list ref] writes:

quoted

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.

quoted

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