Sanjoy Mahajan <[EMAIL PROTECTED]> writes:
> 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).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
