git bisectThe goal of this exercise is to improve git proficiency and to learn
about systematic debugging, using git bisect.
Make sure a Java 17+ JDK and Git are installed. The required software is already installed on attu.cs.washington.edu, if you prefer to do the exercise there.
Not required, but strongly recommended: practice resolving a merge conflict.
The developers of this application published the first release, which they tagged v1.0.0. Unfortunately, the developers introduced a defect at some point after the v1.0.0 release, which has existed in the code since. The automated testing infrastructure did not catch the defect. Since the developers were so excited about coding, they never manually checked a single test run.
The testing infrastructure executes
“./gradlew clean build”. This command builds the
application from scratch and runs all tests. If the command fails (i.e.,
returns a non-zero exit code), then the developers are notified.
Team up in groups of size 2, and self-assign to a group (in the In-class1-Git groupset) on Canvas. (If you are in a Canvas group of size 1, you can still submit.) In the past, groups found a pair-programming set up (in person or using screen-sharing for remote work) to be beneficial.
Clone the following git repository and read its README.md file: https://github.com/mernst/basic-stats
Checkout the most recent commit on the
main branch (git checkout main) and run:
“./gradlew clean build”. The software is defective, but the
command ./gradlew clean build succeeds! Figure out why.
Hint: run “`./gradlew clean build; echo $?” which prints the exit code
of the gradle process.
Check out the commit with tag v1.0.0
(git checkout v1.0.0), and compile and test the application
again. All tests pass on this revision. If that is not
the case, you have done something wrong.
Determine the number of commits between tag v1.0.0 and HEAD (the latest revision on main). Include v1.0.0 and HEAD when counting, and note the command(s) that you used to automatically compute this number.
Familiarize yourself with the git
bisect command. Use git bisect to
identify the commit that introduced
the defect between version v1.0.0 and
HEAD. (You might want to automate
git bisect with a script.) Note the commit hash and log
message of the defect-inducing commit. Verify that you
correctly identified the defect-inducing
commit.
Why does the described automated testing infrastructure not catch the test failure? How could you improve it?
How many commits exist between version v1.0.0 and HEAD (including v1.0.0 and HEAD)? List the command(s) that you used to automatically compute this number.
Which commit (commit hash and message) introduced the defect? How did you verify that this commit indeed introduced the defect?
How many commits, not including v1.0.0 and
HEAD, did git bisect analyze before finding
the first failing commit? List all commands you ran; this will likely be
a series of calls to git bisect, or a call to your script.
The staff must be able to run these commands, by copying (once) from
your document and pasting into a command shell.
What is the best-, worst-, and average-case run-time complexity
of git bisect to discover the defect-inducing commit?
Why?
Which git command can you use to undo an undesirable
commit? Does this command work in your case (for the commit you
identified in question 3)? Briefly explain a problem that may occur when
undoing a commit and what best practices mitigate this problem.
One team member should upload the deliverables to Canvas.