git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCHv2] git bisect old/new

From
Phil Hord <phil.hord@gmail.com>
Date
Jun 15, 2012, 20:20 UTC
Message-ID
<CABURp0qGUvjtOBp8vQ4LqWsWp-5oi+-2GwVq-edQbUnKzXHR-A@mail.gmail.com>
In-Reply-To
<7vlijper0e.fsf@alter.siamese.dyndns.org>
On Thu, Jun 14, 2012 at 1:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 35 quoted lines
>
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 12 of 14 in “git bisect old/new”
  1. git bisect old/newValentin Duperray, Jun 12, 2012
  2. Christian CouderJun 12, 2012
  3. Junio C HamanoJun 12, 2012
  4. Phil HordJun 12, 2012
  5. Christian CouderJun 13, 2012
  6. Junio C HamanoJun 13, 2012
  7. [PATCHv2] git bisect old/newValentin Duperray, Jun 12, 2012
  8. Junio C HamanoJun 12, 2012
  9. duperrav@minatec.inpg.frJun 13, 2012
  10. Christian CouderJun 14, 2012
  11. Junio C HamanoJun 14, 2012
  12. Phil HordJun 15, 2012
  13. Junio C HamanoJun 15, 2012
  14. Christian CouderJun 13, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.