It's nice that QB tries to decide what new revisions where introduced, but it breaks when a branch is rebased in Git. We regularly do this to clean up history and absorb conflicting changes on master, and when we do, the build fails with something like:
06:57:52,837 INFO - Checking out revision 'e64a68f2a6eca3601c2c5e7c2ef4f13c40a7f6b9' of repository 'git-repo'...
06:57:52,839 INFO - Repository setting changed, deleting working directory [/opt/buildagent/workspace/root/castanet/castanet/dev/play-with-rpms]
06:58:01,841 INFO - Getting changes of 'git-repo' since build '4.4.0.dev1753'...
06:58:01,846 ERROR - fatal: bad object 73efa2e587cac0fd4aaf06a16b0e1f225bedd238
06:58:01,848 INFO - Executing post-execute action...
06:58:01,848 ERROR - Step 'master>master-full>checkout' is failed: Failed to run command: git log -1 --date=raw --pretty=format:%cd 73efa2e587cac0fd4aaf06a16b0e1f225bedd238
Command return code: 128
Command error output: fatal: bad object 73efa2e587cac0fd4aaf06a16b0e1f225bedd238
Then we have to reach in and kick it again. :-( It'd be nice if QB could be better behaved here. Perhaps we could setup a default branch it could compare against (say master), and it could use that as a fallback? I'd be happy with it not telling me anything about the included commits as long as it continued the build.