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

Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev

From
Christian Couder <chriscool@tuxfamily.org>
Date
Jul 10, 2008, 23:21 UTC
Message-ID
<200807110121.34656.chriscool@tuxfamily.org>
In-Reply-To
<alpine.DEB.1.00.0807110035180.3279@eeepc-johanness>
Le vendredi 11 juillet 2008, Johannes Schindelin a écrit :
Show 17 quoted lines
> Hi,
>
> On Fri, 11 Jul 2008, Christian Couder wrote:
> > Le jeudi 10 juillet 2008, Junio C Hamano a écrit :
> > >  - "Test this merge-base before going forward, please" will add
> > >    typically only one round of check (if you have more merge bases
> > >    between good and bad, you need to test all of them are good to be
> > >    sure), so it is not "slower nor more complex".
> >
> > By "slower" I meant that it would need more rounds of check on average.
> > By "more complex" I meant that more code is needed.
> >
> > And I think you are right, all the merge bases need to be tested so I
> > will send a patch on top of the patch discussed here.
>
> Good luck.  This will open the scenario where people use a proper
> ancestor as "good" revision.  In this case, you test that.

If a proper ancestor is used as good rev, then the merge base between this good rev and the bad rev is this good rev, and as it is known to be good it doesn't need to be tested by the user. I think my patch handles this well.

Show 9 quoted lines
> If it is 
> "bad" you report that it is the _first_ one.
>
> You are opening a can of worms here, and I doubt that this is a good
> idea.
>
> git-bisect as-is has very precise, and _simple_ semantics, and users
> should really know what they are doing (i.e. not marking something as
> "good" which is on a branch containing a fix).

I think that users don't and can't always know what they are doing. If there is a revert in a branch for example, how can they know all the bugs that it fixes?

> Trying to be too clever here might just make the whole tool rather
> useless.

I don't think so. I think that if user can trust "git bisect" more, they will use it more, and in more automated ways and everyone will win in the end.

Regards, Christian.

Previous: Johannes SchindelinNext: Junio C Hamano
Message 8 of 18 in “bisect: test merge base if good rev is not an ancestor of bad rev”
  1. bisect: test merge base if good rev is not an ancestor of bad revChristian Couder, Jul 10, 2008
  2. Johannes SchindelinJul 10, 2008
  3. Christian CouderJul 10, 2008
  4. Junio C HamanoJul 10, 2008
  5. Junio C HamanoJul 10, 2008
  6. Christian CouderJul 10, 2008
  7. Johannes SchindelinJul 10, 2008
  8. Christian CouderJul 10, 2008
  9. Junio C HamanoJul 10, 2008
  10. Christian CouderJul 10, 2008
  11. Junio C HamanoJul 10, 2008
  12. Johannes SchindelinJul 10, 2008
  13. Junio C HamanoJul 11, 2008
  14. Johannes SchindelinJul 11, 2008
  15. Junio C HamanoJul 10, 2008
  16. Christian CouderJul 13, 2008
  17. Johannes SchindelinJul 13, 2008
  18. Christian CouderJul 22, 2008

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.