From what I can tell the way TeamCity tracks changes for a Git repo from build to build is to look at the last build commit and then look for commits since then. However, if a new commit comes in that rebases things upon an earlier commit, thus removing that last recorded commit from the chain, this logic falls apart.
In these situations, and in the situations of a brand new branch, this seems to result in it grabbing some unknown quantity of commits back in the history, something like 6 weeks worth in the project I'm looking at, or around 150 commits. This leads to,
- Confusing to read what has changed in a recent build.
- Hard to tell what changes might have broken things and resulting in excess emails about broken builds to users unrelated to it.
- Jira Plugin assigns the build to a lot more issues because it's looking at this extended history of changes that aren't really related to this build.
Could this logic for Git be updated to somehow figure the common ancestor commit and use that as the "last built commit"
For a brand new branch it's fairly simple, with the merge-base --fork-point option being able to give the commit the branch was initially created from. I think for a new branch the list of changes made since the branch was created will be the most relevant.
git merge-base --fork-point <branch>
For a rebased build, you can run merge-base from the last known commit and the new latest commit. Then use that as the new "last built commit". Unfortunately if the Git server has pruned the abandoned commit and the TeamCity server no long has a cached copy that includes it, then this isn't an option. Instead could store a list of the recent commits so that in the majority of cases, it can still determine a more useful list of changes. Worst case, reverting to the last commit built from a prior build, or back to the fork-point for the branch would still be preferable over current behavior.