Bisect for finding bug-introducing commits in Git - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Bisect Start and Marking Commits

You start a git bisect session with git bisect start. You mark commit abc123 as bad and commit def456 as good. What is the next step git expects you to do?

A Manually check out the next commit git selects and mark it as good or bad

B Reset the bisect session with <code>git bisect reset</code>

C Merge the good commit into the bad commit branch

D Run <code>git bisect run</code> immediately to automate testing

💡 Hint

Think about how git bisect narrows down the commit range step by step.

After marking the known good and bad commits, git bisect checks out a commit in the middle. You must test it and mark it as good or bad manually. This helps git narrow down the commit that introduced the bug.

💻 Command Output

intermediate

Bisect Command Output Interpretation

You run git bisect bad after testing a commit. Git outputs:

Bisecting: 3 revisions left to test after this (roughly 2 steps)
Next commit to test is 789abcde

What does this output mean?

A Git encountered an error and cannot continue bisecting

B Git found the bad commit at 789abcde and bisect is finished

C There are 3 commits left to check, and git will take about 2 more steps to find the bad commit

D You must reset bisect because the range is invalid

💡 Hint

Look at the number of revisions left and the next commit hash.

The output shows how many commits remain to test and which commit git will check out next. It helps you understand progress.

❓ Troubleshoot

advanced

Bisect Session Stuck on a Commit

During a bisect session, you test a commit but the build fails and you cannot determine if it is good or bad. What is the best way to proceed?

A Skip the commit using <code>git bisect skip</code> and continue

B Mark the commit as bad to continue bisecting

C Mark the commit as good to continue bisecting

D Abort the bisect session with <code>git bisect reset</code>

💡 Hint

Think about how to handle commits that cannot be tested.

If you cannot test a commit, skipping it allows git to ignore it and continue bisecting with other commits.

🧠 Conceptual

advanced

Understanding Bisect Algorithm Efficiency

Git bisect uses a binary search algorithm to find the bad commit. If you have 128 commits between good and bad, what is the maximum number of steps git bisect will take to find the bad commit?

A 128 steps

B 7 steps

C 64 steps

D 256 steps

💡 Hint

Binary search halves the search space each step.

Binary search cuts the number of commits to check in half each step. For 128 commits, log2(128) = 7 steps max.

✅ Best Practice

expert

Automating Bisect with a Test Script

You want to automate git bisect using git bisect run with a test script that exits 0 if the commit is good and 1 if bad. Which of the following scripts is correct for this purpose?

A

#!/bin/sh
make test; exit 0

B

#!/bin/sh
exit 0

C

#!/bin/sh
if make test; then exit 1; else exit 0; fi

D

#!/bin/sh
make test && exit 0 || exit 1

💡 Hint

The script must exit 0 for good commits and non-zero for bad commits.

The script runs tests and exits 0 if tests pass (good commit), or exits 1 if tests fail (bad commit). This matches git bisect run expectations.

Practice

1. What is the main purpose of git bisect?

easy

A. To delete old commits from history

B. To merge two branches automatically

C. To create a new branch from the current commit

D. To find the first commit that introduced a bug

Solution

1. Step 1: Understand the role of git bisect

   Git bisect helps identify which commit introduced a bug by testing commits between a known good and a bad commit.

2. Step 2: Compare with other git commands

   Merging branches, deleting commits, or creating branches are different git operations unrelated to bisect.

3. Final Answer:

   To find the first commit that introduced a bug -> Option D

4. Quick Check:

   git bisect = find bug commit [OK]

Hint: Bisect narrows down bug commit by testing between good and bad [OK]

Common Mistakes:

• Confusing bisect with merge or branch commands
• Thinking bisect deletes commits
• Assuming bisect creates branches

2. Which command correctly starts a bisect session assuming HEAD is bad and v1.0 is good?

easy

A. git bisect start v1.0 HEAD

B. git bisect start HEAD v1.0

C. git bisect begin HEAD v1.0

D. git bisect init v1.0 HEAD

Solution

1. Step 1: Recall git bisect start syntax

   The correct syntax is git bisect start <bad> <good>, where the first argument is the bad commit and the second is the good commit.

2. Step 2: Match the given commits

   Since HEAD is bad and v1.0 is good, the command is git bisect start HEAD v1.0.

3. Final Answer:

   git bisect start HEAD v1.0 -> Option B

4. Quick Check:

   git bisect start bad good = start [OK]

Hint: Start bisect with bad commit first, then good commit [OK]

Common Mistakes:

• Reversing good and bad commits in the command
• Using incorrect command like bisect begin or init
• Omitting the start keyword

3. Given this bisect session output:

Bisecting: 3 revisions left to test after this (roughly 2 steps)
Testing commit abc1234

If you run git bisect good and then git bisect bad on the next commit, what will git do next?

medium

A. Git will narrow down the range and checkout the next commit to test

B. Git will end the bisect session immediately

C. Git will reset to the original branch without changes

D. Git will throw an error because you cannot mark good then bad consecutively

Solution

1. Step 1: Understand bisect workflow

   Marking commits as good or bad tells git which side of the commit range to keep searching. After marking, git checks out the next commit to test.

2. Step 2: Analyze the given commands

   Marking one commit good, then the next bad, narrows the search range. Git continues bisecting until it finds the first bad commit.

3. Final Answer:

   Git will narrow down the range and checkout the next commit to test -> Option A

4. Quick Check:

   Mark good/bad -> git picks next commit [OK]

Hint: Mark commits good/bad to let git pick next test commit [OK]

Common Mistakes:

• Thinking bisect ends after one good and one bad mark
• Assuming git resets automatically after marking
• Believing marking good then bad consecutively causes error

4. You started a bisect session but accidentally marked a good commit as bad. What is the best way to fix this?

medium

A. Edit the .git/BISECT_LOG file manually to fix the mistake

B. Run git bisect skip on the wrong commit

C. Run git bisect good on the same commit to correct it

D. Run git bisect reset and start over

Solution

1. Step 1: Understand bisect marking correction

   Git bisect allows re-marking a commit to correct its status if marked incorrectly.

2. Step 2: Correct the marking

   Run git bisect good on the commit you accidentally marked as bad to update the bisect state.

3. Final Answer:

   Run git bisect good on the same commit to correct it -> Option C

4. Quick Check:

   Re-mark good/bad to correct [OK]

Hint: Re-mark the commit with git bisect good to fix [OK]

Common Mistakes:

• Thinking you must reset instead of re-marking
• Editing internal git files manually
• Using skip to fix a marking error

5. You have a large project with 1000 commits. You know commit abc123 is good and def456 is bad. You want to find the first bad commit using git bisect. Which sequence of commands correctly performs this task?

hard

A. git bisect start def456 abc123; git bisect bad def456; git bisect good abc123; test commits; git bisect reset

B. git bisect start abc123 def456; git bisect bad abc123; git bisect good def456; test commits; git bisect reset

C. git bisect start def456 abc123; git bisect good def456; git bisect bad abc123; test commits; git bisect reset

D. git bisect start abc123 def456; git bisect good def456; git bisect bad abc123; test commits; git bisect reset

Solution

1. Step 1: Start bisect with bad then good commit

   The correct syntax is git bisect start <bad> <good>. Since def456 is bad and abc123 is good, the command is git bisect start def456 abc123.

2. Step 2: Mark the known commits correctly

   Mark the bad commit with git bisect bad def456 and the good commit with git bisect good abc123. Then test intermediate commits as git suggests.

3. Step 3: Finish bisect session

   After finding the first bad commit, run git bisect reset to return to the original branch.

4. Final Answer:

   git bisect start def456 abc123; git bisect bad def456; git bisect good abc123; test commits; git bisect reset -> Option A

5. Quick Check:

   Start with bad then good, mark correctly, reset [OK]

Hint: Start bisect with bad then good commit, mark accordingly [OK]

Common Mistakes:

• Reversing good and bad commits in start command
• Marking commits with wrong status
• Skipping reset after bisect finishes