What is dangerous about rebase-2, or how rebase prevented a bug from searching
One day, Anton, a senior programmer, sipping coffee and recalling Vasya who was dismissed in the previous article , was looking through the next ticker in the bug tracker. 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 began to search for the reasons for this behavior.
The company used rebase, the history of commits was linear, and searching through it gave Anton a pleasure.
Suddenly:
- Hmm ... The project is not compiled, the test will not work out. Well, never mind, let's skip: git bisect skip .
- What kind of nonsense? Again not compiled. Again miss ...
- Again ??? What
After a while, a bleak picture opened up before Anton: 30 commits for which the project is not going to, and somewhere among them a commit with an error.
Anton dialed Vasya's number.
Anton: - Hi, Vasily! Tell me where in the repository 30 revisions for which the project is not going?
Vasya: - Ah ... I remember, I remember. I developed an important feature in my branch, it turned out 30 commits, each one complete change, I ran all the tests before the commits, all as a textbook. But at this time, Peter in the wizard greatly changed the API that was used in my commits. Therefore, when I locally rebase, my commits ended up after Petya, and the project stopped collecting them.
Anton: - And what, you did not check it, before you push?
Vasya: - Of course, I checked. And I created a commit with the transition of my feature to a new API, after which the project began to build again.
Anton: - And how can I now locate the error in these 30 commits?
Vasya: - Sorry, Anton. I'm fired, and now it's not my problem.
Anton began to search for the cause of the bug in a very important project. The company uses merge, the history of commits is non-linear, manual search through history does not give Anton joy, so he delegates this business to git-bisect using a pre-prepared script.
Git bisect merrily ran through commits, automatically running a test script and placing good / bad tags, missed the only non-working commit and issued a result.
')
Anton: - Hey, Vasily! You have an error in the f35d440 commit .
Vasya: - Ok, I'll see.
In 5 minutes:
Vasya: - Done, fixed.
Anton: OK.
Moral: any rebase (including a local one) changes the context in which commits were written, and “broken” revisions may remain in 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 history of commits was linear, and searching through it gave Anton a pleasure.
Suddenly:
- Hmm ... The project is not compiled, the test will not work out. Well, never mind, let's skip: git bisect skip .
- What kind of nonsense? Again not compiled. Again miss ...
- Again ??? What
@#$%^ launched so many broken commits?After a while, a bleak picture opened up before Anton: 30 commits for which the project is not going to, and somewhere among them a commit with an error.
Anton dialed Vasya's number.
Anton: - Hi, Vasily! Tell me where in the repository 30 revisions for which the project is not going?
Vasya: - Ah ... I remember, I remember. I developed an important feature in my branch, it turned out 30 commits, each one complete change, I ran all the tests before the commits, all as a textbook. But at this time, Peter in the wizard greatly changed the API that was used in my commits. Therefore, when I locally rebase, my commits ended up after Petya, and the project stopped collecting them.
Anton: - And what, you did not check it, before you push?
Vasya: - Of course, I checked. And I created a commit with the transition of my feature to a new API, after which the project began to build again.
Anton: - And how can I now locate the error in these 30 commits?
Vasya: - Sorry, Anton. I'm fired, and now it's not my problem.
At this time in a parallel reality ..
Anton began to search for the cause of the bug in a very important project. The company uses merge, the history of commits is non-linear, manual search through history does not give Anton joy, so he delegates this business to git-bisect using a pre-prepared script.
git bisect run ./testscript.sh Git bisect merrily ran through commits, automatically running a test script and placing good / bad tags, missed the only non-working commit and issued a result.
f35d44060c4f2ae251046c0c20ae1e1f68044812 is the first bad commit ')
Anton: - Hey, Vasily! You have an error in the f35d440 commit .
Vasya: - Ok, I'll see.
In 5 minutes:
Vasya: - Done, fixed.
Anton: OK.
Moral: any rebase (including a local one) changes the context in which commits were written, and “broken” revisions may remain in history. Remember this.
Sample project on github .
Source: https://habr.com/ru/post/179673/
All Articles