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

Re: [RFC/PATCH]: reverse bisect v 2.0

From
Jeff King <peff@peff.net>
Date
Oct 12, 2011, 20:14 UTC
Message-ID
<20111012201410.GB1502@sigill.intra.peff.net>
In-Reply-To
<7vr52ibydy.fsf@alter.siamese.dyndns.org>
On Tue, Oct 11, 2011 at 09:57:13PM -0700, Junio C Hamano wrote:
> With an obvious addition of non-interactive short-cut subcommands "git
> bisect yes" and "git bisect no", I think --removed= is a much better
> wording than --used-to= I suggested in the discussion.
Agreed.
Show 8 quoted lines
> I however am still worried about the flipping of the mapping between
> <good,bad> and <yes,no> this design requires. What are we going to do to
> the labels of low-level machinery (i.e $GIT_DIR/refs/bisect/bad and
> $GIT/refs/bisect/good)? They appear in "bisect visualize" and I was hoping
> that it would be simpler in the code if we do not have to change them in
> such a way that depends on this introduced/removed switch, and that was
> the reason why I was trying to see if we can solve this without the
> switchable mapping between <good,bad> and <yes,no>.

Hmm. I hadn't thought about the labels. In a yes/no situation, though, couldn't you use the labels as the user sees them?

Then it is simply a matter of flipping yes/no inside the bisect script whenever we interact with the user (i.e., "git bisect yes") or when we interact with the on-disk labels.

Certainly it's more complex than not allowing reversing, though.
Show 8 quoted lines
> More specifically, I was hoping that we can rename "good" to "old" and
> "bad" to "new" unconditionally and be done with it. We would ask the user
> "What did the code used to do in the olden days?" and "Does this version
> behave the same as it used to?". The possible answers the user can give
> are "git bisect old" (it behaves the same as the older versions) and "git
> bisect new" (it behaves the same as the newer versions). Then we do not
> have to worry about having to flip the meaning of <yes> and <no> at the UI
> level.

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.
-Peff
Previous: Junio C Hamano
Message 17 of 17 in “RFC: reverse bisect”
  1. Michal VyskocilSep 29, 2011
  2. Sverre RabbelierSep 29, 2011
  3. Johannes SixtSep 29, 2011
  4. Jeff KingSep 30, 2011
  5. Frans KlaverSep 30, 2011
  6. Michal VyskocilSep 30, 2011
  7. : reverse bisect v 2.0Michal Vyskocil, Sep 30, 2011
  8. Junio C HamanoSep 30, 2011
  9. Jeff KingOct 3, 2011
  10. Junio C HamanoOct 3, 2011
  11. Jeff KingOct 4, 2011
  12. Junio C HamanoOct 4, 2011
  13. Christian CouderOct 4, 2011
  14. Junio C HamanoOct 4, 2011
  15. Andrew ArdillOct 7, 2011
  16. Junio C HamanoOct 12, 2011
  17. Jeff KingOct 12, 2011

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.