Ever had a problem come up somewhere within a chain of commits, and you’re not sure which change caused the problem? Up to now, we’ve usually addressed this by doing a binary search between the last commit and the latest commit we can find where the problem hasn’t yet been introduced. I consider myself fairly experienced with Git, but I had no idea that it would do it for you!
The git bisect command is your friend in this case. An excellent blog post explaining how to use it can be found here:
I found a very useful tip on StackOverflow for doing this. The command to use is:
git branch --set-upstream master origin/master
This adds the following to your Git config file:
remote = origin
merge = refs/heads/master
I recently experienced some odd behaviour with Git and Gerrit. I created a short-lived branch on a project in Gerrit. Once I was done with it, I deleted the branch using the Gerrit admin page.
When I listed the remote branches for the project (using git branch -a), it was still showing the remote branch which I deleted! Eventually, after a bit of research online, I found what the problem was. The branch had been deleted on the remote repository, but I hadn’t yet updated my remote tracking branches yet. Calling “git fetch” or “git pull” won’t update them either. To do this, you need to call:
git remote prune origin
(For a remote with a different name, substitute it in for origin). This deletes any stale remote tracking branches.