Git Bug Resolve: bisect run failed to locate the right commit, not git bug

[李祐棠]

Dear git developer:

On August 27, I report a bug on git bisect: 
bisect run failed to locate the right commit

Today, my friend told me that the problem may be caused by the python compiled 
file *.pyc.
Since if python see the pyc is a new compiled, it will directly run *pyc file 
but update it.

When we use bisect-run, it quickly checkout different version and run the 
script to test it.
It's so fast that the *pyc file are still new files, so python run *.pyc and 
get same result.
That's the wrong result came from.

There are two way to avoid this problem:
First is delete all *.pyc before python run, add a test.sh with following 
content:
find . -name *.pyc -exec rm {} \;
./autoscript.py

Second is let python run slower, adding a delay in autoscript.py:
import time
time.sleep(1)

Both method let git-bisect-run give the right result.

Sorry about the wrong bug report, it prove that git-bisect-run is very very 
fast -- too fast to cause some mistake lol

Sincerely 
YodaLee
20140828

Git Bug Report: bisect run failed to locate the right commit

[李祐棠]

Dear Git developers:

I just found a suspicious bug that might cause by git-bisect run. 

Version:
The git version is 1.9.2, running on Archlinux 3.14.2

The step to produce the error:
Here is the repository I participate: 
https://github.com/gawel/pyquery

It got a issue #74, that gives a wrong result in version 1.2.8
and this is fixed in 1.2.9

Here is the manual test script I use is manualscript.py:

I use git bisect manually, search from 1.2.9(bad) to 1.2.8(good), I locate the 
commit that fixes this issue. The running log is attached in this file(manual).

However if I use the automatic script
git bisect run
with the script auto script:

It will give a wrong answer, the log file is also attached(auto)

I wonder there might be some bugs in bisect run, that give the different 
result. The bisect run give the wrong result, and manually there is no error in 
bisect

The test step is a little complicated, and I have to compress the test script 
and result in tar since mail server think the test code as spam. it's very 
sorry to bother you.

Sincerely 
YodaLee 

20140827

testfile.tar
Description: testfile.tar

Git Bug Report: bisect run failed to locate the right commit, detail testing

[李祐棠]

Dear git developers:

Allow me to describe the testing situation more detail:

First the testing repository is in 
https://github.com/gawel/pyquery
my git version is 1.9.2 running on Archlinux 3.14.2

I try to track issue #74(which is closed now)
It give result False/True in version 1.2.8(good), and result False/False in 
version 1.2.9(bad).

The testing script are manualscript.py and autoscript.py
Both of them implement the test case describe in issue #74.
Th only difference is that autoscript.py call sys.exit() to return the testing 
value.

First we test with git-bisect manually with manualscript.py:
The testing result is shown in 'bisectmanual_manualscript'

Then we test with git-bisect manually with autoscript.py
This time we echo $? every time we execute autoscript.py, and the testing 
result is shown in 'bisectmanual_autoscript'

In both situation the script give the same result, and the return value of 
autoscript.py is correct, too.

However, if we use git-bisect-run with autoscript.py, it will show a different 
result. The testing result is shown in 'bisectrun'.
The log shows that autoscript.py output False/False all the way.
As Mr. Couder said, there is some checkout commit that autoscript.py and 
manualscript.py give different result, for example commit 
d22159bb32510e9eacf6c5c2408a79792e99fe76.
If I checkout this commit outside bisect state and run manualscript.py and 
autoscript.py, they both give False/True result.  
So, I guess there is some problem in the checkout procedure in bisect-run, so 
the commit didn't successfully checkout.

ps. I found this time the bisect run give me another version of output compared 
to the last version I sent to everybody OAO. That is weird.

Thank for helping.
Sincerely 
YodaLee
20140828


testfile.tar
Description: testfile.tar