Bamboo failed shallow clone recovery mode

Summary

For Git workflows where developers change the history of branches (by using rebase, squash, etc.) on their branch before force pushing changes to Bitbucket, the source code checkout task can reach a situation where it's unable to successfully checkout the revision that triggered the build if shallow clones are enabled because it is attempting to checkout a commit that was removed from the branch/not in the history pulled down by the fetch.

Suggestion

When checking out a revision post a shallow clone fails due to the commit not being present in the shallow history, Bamboo enters a "recovery mode" where it fetches the history for that branch in an empty repo. For some use cases, it would be best if Bamboo would, for the recovery logic, either do a full clone of the branch to the working directory; or add to the fetch command to pull the history for the ${bamboo_planRepository_1_revision} commit.