Re: [PATCHv2] git bisect old/new

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christian Couder <christian.couder@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]