Debugging with git

The setup script is located in the git.zip file in the exercsises folder.

Run ./debugging.sh for setup!

git blame

git blame annotates each line with commit it was last changed. It can also detect movements and copies of lines.

Instructions

Run git blame -C file2.txt
Run git show to show the last commit
Run git blame file2.txt

Questions

What lines are moved from where?
What is the default lower limit for git to consider a line copied or moved?
Who edited the moved lines?
According to the commit, who is the author?
According to the standard blame, who is the author?

Answers

the second line is moved
20 chars
Your configured user, in my case maschmi
Hans
Hans

git bisect

Imagine the following situation. Sometime during the last weeks a subtle bug was introduced. You have no idea when and where this happened. Lucky for you, the team does rather small commits and now it is only a question to find the specific commit. Even better, there is a simple, automatic test to detect the bug. git bisect helps you to find this commit fast!

Preparations

Run ./test.sh and watch the test fail
We assume the commit with add new stuff to file1 was a good commit. Run git log --oneline to find the commit hash
Run git checkout commitHash to check this out this revision (we detach the head and check out this revision)
Run ./test.sh again and watch if succeed
Run git checkout debugging to switch to back to the debugging branches HEAD

Bisecting

HINT: There are two aliases defined

git good => git bisect good
git bad => `git bisect bad

Run git bisect start
Mark the current HEAD as bad with git bisect bad
Mark the commitHash from the good commit as good with git bisect good commitHash
Now we start the loop: Run ./test.sh and then either git bisect bad or git bisect good
Stop when a commit is printed
Run git bisect reset to exit bisect mode

Questions

How many steps were needed to find the commit?
Which commit introduced the failure?

Answers

7
commit 33