May 15, 2013 at 16:00What is the danger of rebase-2, or how rebase prevented the bug from searching
Once, a senior programmer Anton, while drinking coffee and recalling Vasya , who was dismissed in a previous article , was looking at another ticket in a bugtracker. In the ticket it was said that one of the programs in a very important project began, under certain conditions, to return “BAD” instead of “GOOD”. Without thinking twice, Anton wrote a test script and proceeded to search for the reasons for this behavior.
The company used rebase, the commit history was linear, and it was a pleasure to search Anton.
Suddenly:
- Hmm ... The project does not compile, the test cannot be run. Well, it doesn’t matter, let’s skip: git bisect skip .
- What nonsense? Again not compiled. Skip again ...
- Again ??? Which
After some time, a bleak picture appeared in front of Anton: 30 commits, on which the project is not going to, and somewhere among them a commit with an error.
Anton dialed Vasya's number.
Anton: - Hello, Vasily! Tell me, where are the 30 revisions in the repository from which the project is not going to be?
Vasya: - Ah ... I remember, I remember. I developed an important feature in my branch, it turned out 30 commits, each one one whole change, before the commits I ran all the tests, everything was as in a textbook. But at this time Petya in the wizard greatly changed the API that was used in my commits. Therefore, when I did a rebase locally, my commits were after Petiny, and the project stopped collecting on them.
Anton: - And what, you did not check it before you push?
Vasya: - Of course I checked. And he created a commit with the transition of my feature to the new API, after which the project began to assemble again.
Anton: - And how can I now localize the error in these 30 commits?
Vasya: - Sorry, Anton. I am fired and now this is not my problem.
Anton began to search for the cause of the bug in a very important project. The company uses merge, the commit history is non-linear, manual search by history does not give Anton joy, so he delegates this git-bisect business using a pre-prepared script.
Git bisect cheerfully ran the commits, automatically running the test script and setting the good / bad labels, skipped the only non-working commit and returned the result.
Anton: - Hey, Vasily! You have an error in f35d440 .
Vasya: - Well, I'll see.
After 5 minutes:
Vasya: - Done, corrected.
Anton: ok.
Moral: any rebase (including local) changes the context in which commits were written, and “broken” revisions can remain in the history. Remember this.
Sample project on github .
testscript.sh
#!/bin/bash
result=`./project.sh`
echo $result
if [[ "$result" == "GOOD" ]]
then
echo "Test passed"
exit 0
elif [[ "$result" == "BAD" ]]
then
echo "Test failed"
exit 1
else
echo "Can not apply test"
exit 125
fi
git bisect start
./testscript.sh
git bisect bad
./testscript.sh
git bisect good
…
The company used rebase, the commit history was linear, and it was a pleasure to search Anton.
Suddenly:
- Hmm ... The project does not compile, the test cannot be run. Well, it doesn’t matter, let’s skip: git bisect skip .
- What nonsense? Again not compiled. Skip again ...
- Again ??? Which
@#$%^started up so many broken commits? After some time, a bleak picture appeared in front of Anton: 30 commits, on which the project is not going to, and somewhere among them a commit with an error.
Anton dialed Vasya's number.
Anton: - Hello, Vasily! Tell me, where are the 30 revisions in the repository from which the project is not going to be?
Vasya: - Ah ... I remember, I remember. I developed an important feature in my branch, it turned out 30 commits, each one one whole change, before the commits I ran all the tests, everything was as in a textbook. But at this time Petya in the wizard greatly changed the API that was used in my commits. Therefore, when I did a rebase locally, my commits were after Petiny, and the project stopped collecting on them.
Anton: - And what, you did not check it before you push?
Vasya: - Of course I checked. And he created a commit with the transition of my feature to the new API, after which the project began to assemble again.
Anton: - And how can I now localize the error in these 30 commits?
Vasya: - Sorry, Anton. I am fired and now this is not my problem.
At this time in parallel reality ..
Anton began to search for the cause of the bug in a very important project. The company uses merge, the commit history is non-linear, manual search by history does not give Anton joy, so he delegates this git-bisect business using a pre-prepared script.
git bisect run ./testscript.sh
Git bisect cheerfully ran the commits, automatically running the test script and setting the good / bad labels, skipped the only non-working commit and returned the result.
f35d44060c4f2ae251046c0c20ae1e1f68044812 is the first bad commit
Anton: - Hey, Vasily! You have an error in f35d440 .
Vasya: - Well, I'll see.
After 5 minutes:
Vasya: - Done, corrected.
Anton: ok.
Moral: any rebase (including local) changes the context in which commits were written, and “broken” revisions can remain in the history. Remember this.
Sample project on github .