What 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.
    echo $result
    if [[ "$result" == "GOOD" ]]
        echo "Test passed"
        exit 0
    elif [[ "$result" == "BAD" ]]
        echo "Test failed"
        exit 1
        echo "Can not apply test"
        exit 125

    git bisect start
    git bisect bad
    git bisect good

    The company used rebase, the commit history was linear, and it was a pleasure to search Anton.
    - 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 .

    Also popular now: