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

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

From
Christian Couder <christian.couder@gmail.com>
Date
Apr 21, 2017, 12:29 UTC
Message-ID
<CAP8UFD19DVqQLHBta74uLcFPwJaRUKF8Ppmnhct5ub=OkKSqCQ@mail.gmail.com>
In-Reply-To
<alpine.DEB.2.20.1704211135430.3480@virtualbox>

On Fri, Apr 21, 2017 at 11:50 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 5 quoted lines
>
> Since that "let's aggregate everything and only push out the final result
> at the end of the day" approach does not really allow the Continuous
> Testing to identify problems associated with individual topic branches, I
> have another job that bisects the breakages
Great!
> (with all associated problems
> I reported earlier, as you apply some patches on top of really ancient
> commits and bisect wants to test all merge bases first)

First bisect should ask you to test merge bases only if there are "good" commits that are not ancestors of the "bad" commit. So I don't know how you want to bisect, but it seems to me that you could just go back to a previous know "good" commit when the one you have is not an ancestor of the "bad" commit. This would get rid of the whole merge base problem.

Second yeah there is probably an old bug in bisect there. In theory in most cases bisect should ask you to test only one merge base, as:

- if the merge base is "bad", it means that the bug has been fixed
between the merge base and your "good" commit, and bisecting will
stop,
- if the merge base is "good", it means that all the merge bases that
are ancestor of this merge base are also good, so there is no need to
test them

But that theory can work only if bisect is asking you to test a merge base that is a descendant of many (if not all the other merge bases), but unfortunately I don't think bisect is smart enough for that yet.

> because the
> required time *definitely* would let Travis time out all the time. Those
> bisect results are even less visible than the Travis results, see e.g.
> https://github.com/git/git/commit/2e3a8b9035a#commitcomment-21836854.
Nice that they exists though!
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 14 of 29 in “What's cooking in git.git (Apr 2017, #04; Wed, 19)”
  1. Junio C HamanoApr 20, 2017
  2. Duy NguyenApr 20, 2017
  3. Jeff KingApr 20, 2017
  4. Junio C HamanoApr 20, 2017
  5. Junio C HamanoApr 20, 2017
  6. Lars SchneiderApr 20, 2017
  7. Junio C HamanoApr 20, 2017
  8. Johannes SchindelinApr 20, 2017
  9. Brandon WilliamsApr 20, 2017
  10. Brandon WilliamsApr 20, 2017
  11. Junio C HamanoApr 21, 2017
  12. Junio C HamanoApr 20, 2017
  13. Johannes SchindelinApr 21, 2017
  14. Christian CouderApr 21, 2017
  15. Johannes SchindelinApr 22, 2017
  16. Christian CouderApr 22, 2017
  17. Johannes SchindelinApr 24, 2017
  18. Johannes SixtApr 22, 2017
  19. Johannes SchindelinApr 24, 2017
  20. Philip OakleyApr 24, 2017
  21. Christian CouderApr 25, 2017
  22. Christian CouderApr 25, 2017
  23. Johannes SixtApr 25, 2017
  24. Junio C HamanoApr 25, 2017
  25. Johannes SixtApr 25, 2017
  26. Junio C HamanoApr 24, 2017
  27. Johannes SchindelinApr 24, 2017
  28. Ævar Arnfjörð BjarmasonApr 24, 2017
  29. Junio C HamanoApr 25, 2017

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.