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

Re: bisect gives strange answer

From
Junio C Hamano <junkio@cox.net>
Date
Aug 7, 2005, 17:06 UTC
Message-ID
<7vvf2hy8vo.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<E1E14Hj-0001Nt-00@skye.ra.phy.cam.ac.uk>
Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> writes:
Show 5 quoted lines
> I will redo those tests but rebuilding in place after each bisection
> (with -f added to all the git checkout uses in git-bisect-script) and
> see whether I get the same results.  If I don't, it could be due to
> git or git-bisect (but not so likely with the -f switch) or to the
> build system.  Will keep you and Junio posted.

I thought the lack of '-f' was a plausible explanation, but here is what I just did. The same bisect sequence in your example, making sure the state of working tree matches what the commit being tested:

    $ git bisect start
    $ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3
    $ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6
    Bisecting: 42 revisions left to test after this
    $ cat .git/HEAD
    b2f571026594884e7a2a3f8bc6ad5c92e0703330
    $ git bisect good; cat .git/HEAD; git-diff-cache -r bisect
    Bisecting: 30 revisions left to test after this
    450008b5a62bb09445ae05c4d01d510386c9435d
    $ git bisect good; cat .git/HEAD; git-diff-cache -r bisect
    Bisecting: 15 revisions left to test after this
    a9df3597fec5472d0840fbfdc2a3fac5268f7d08
    $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect
    Bisecting: 8 revisions left to test after this
    28e8c3ad9464de54a632f00ab3df88fa5f4652d1
    $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect
    Bisecting: 4 revisions left to test after this
    c774e93e2152d0be2612739418689e6e6400f4eb
    $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect
    Bisecting: 2 revisions left to test after this
    b4634484815e1879512a23e4f59eef648135c30a

So it does not appear to me that lack of '-f' is a problem. Without the flag, checkout does "read-tree -m -u" which means to update the working tree to match the new tree being read (this includes the removal of files from the working tree that were registered in the original index file that are not in the next tree).

Previous: Sanjoy Mahajan
Message 11 of 11 in “bisect gives strange answer”
  1. Sanjoy MahajanAug 4, 2005
  2. Junio C HamanoAug 4, 2005
  3. Sanjoy MahajanAug 4, 2005
  4. Greg KHAug 4, 2005
  5. Sanjoy MahajanAug 4, 2005
  6. Dave JonesAug 4, 2005
  7. Sanjoy MahajanAug 4, 2005
  8. Junio C HamanoAug 4, 2005
  9. Sam RavnborgAug 4, 2005
  10. Sanjoy MahajanAug 5, 2005
  11. Junio C HamanoAug 7, 2005

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.