Handle git history rewrite

Answered

Environment: TeamCity Professional 2019.2.2 (build 71923) with git VCS roots.

At least on a couple of git repos, we wish to rewrite git history because some large files crept in. Are there any recommendations to follow ?
Specifically, if the tips of some active branches get a new commit, is there a way to make TeamCity record that it built a different commit the last build it ran ?

For the sake of an example VCS Root, before git history rewrite:
master - abcd123
feature/foo-bar - mnop456
something-else - ijkl789

All 3 branches built by TeamCity (successfully or not). Now after history rewrite, the tips looks like:
master - dj489de
feature/foo-bar - e48d3js
something-else - djk43ye

We don't want TeamCity to attempt to find changes right from the ancestor until which it had build history. We'd just want to reset the VCSRoot such that it records last built commits on those branches as newer ones.

What steps should we follow ?

2 comments
Comment actions Permalink

Hello Parag,

I`ve just made a few tests on a branch that has been force-pushed to. Let me share the results explaining the underlying logic here.

Initial setup:
build configuration is watching master branch, last known revision: 38ee8a33cb8bd0e2f23679c105ce4289e9e4fefa (later referred to as R1), there is a build on this revision

I`m hard resetting to e036931dc4073ccbc6ee3f86f927aa2ad00a87a5 (referred to as R2) which is an earlier commit in master, unknown to TeamCity. TeamCity recognizes the revision (so when I start a build on master branch, it is started with a new revision), but there are no changes reflected in the Changes tab. What happens is that a last known revision (note that it is not necessarily last revision we have a build on, but rather last revision collected from VCS) could not be accessed on the remote repository - so we pick the newest revision and use it as a last known revision from now on. That means that on a newer commit basing of that revision, we`ll start showing the changes delta and hint it properly on UI too. No graph traversal to try and locate the ancestor will take place.

Now, I`m hard resetting to R1 again. However, this revision is known to TeamCity (we keep track of all revisions per VCS root, storing a hash under internal ID which is used to determine the order of revisions) - so if I run a new build, it will report as a history build (because we know that there is a R2 which is more "fresh"). Again, if we`ll see a newer commit basing on this revision it will also be handled as usual.

To sum up - TeamCity will use the current state of the branches after history rewrite as a default behavior. 
I hope this will prove useful; please let me know if you would like any additional details on the above.

0
Comment actions Permalink

Thank you Fedor. Will give this a try early next week on test repo and a sample deployment. Will share the results on this thread soon after.

0

Please sign in to leave a comment.