Pending changes not calculated correctly after changing git VCS root

I began a build job based on a git repository that was building from "refs/heads/master". After this had been building for awhile, we changed things a bit internally and began to build instead from "refs/builds/master", where refs/builds/master is always one commit ahead of refs/heads/master, with a special commit message for the build server.

Since this change was implemented, the "Pending Changes" calculation has been a bit broken, so that every build counts every commit since the change to refs/bulds/master happened as "new". If I go to the build config's "Change log" view, it properly shows which changes come in between which builds.

Any way to fix this without creating a new build configuration? Is there a way to make the build config "forget" that it used to be on refs/heads/master?

2 comments
Comment actions Permalink

Hi,

Can you please provide screenshots of incorrect changes calculation?

0
Comment actions Permalink

Actually, it turns out this is due to some intricacies of how I was branching.

             v1          v3
             /           /
A --- B --- C --- D --- E
                   \
                   v2


I had separate build commits v1, v2, v3, which were not in `master` for the sake of implementing our own versioning scheme. Then I had tagged which build commit was the latest one. As an example, once I update from `v1` to `v2`, the build history from would no longer inlcude `v1` anymore. And so it would calculate versions back to the last common point before any of the build commits, namely, `B`. So, builds for C, D, and E, and anything else moving forward, would always calculate pending changes back to B.

So, we simply modified our scheme a bit to not entirely lose sight of the build commits, and it is working well again.

Turns out it didn't have anything to do with changing the vcs root.

0

Please sign in to leave a comment.