Allow repo normalization to be disabled

[mycroes]

Currently repo normalization is triggered when a buildserver is detected. I'm not sure what the original intention of repo normalization is, but for me it's actually making things worse. I use Jenkins to build NuGet packages for every change made in Gerrit. These changes are normally against the develop branch, but when Jenkins is building the commits they're not yet merged. Because they are intended for merging into develop I let Jenkins checkout the change into a local develop branch as well. However, when GitVersion does normalization, it will reset develop to origin/develop, causing the dreaded HEAD had moved exception (which makes sense, because the local develop is always newer than origin/develop in this scenario).

For now I managed to work around this by clearing the JENKINS_URL environment variable, which causes GitVersion not to detect any buildserver and will let it skip repo normalization and use what Jenkins has provided. This way I actually get the expected version, but it would actually be a lot nicer if GitVersion would just stick to resolving the version instead of deciding what my repository should look like.

[jdombier]

I agree with you, I have "similar" issue caused by this normalization. I were very confused to not reproduce this issue localy, then i discover that the behavior is different on build agents.

[JRLRJ]

The normalisation code even says:

This is designed to be run only on the build server which checks out repositories in different ways.

The implementation doesn't differentiate between build servers, it's on no matter which one is in use. Can anyone comment on why that is?

I'm not sure what the best approach to fix would be, would this be a config property, a build parameter, or something else entirely?

[asbjornu]

I agree the current normalization code isn't optimal. Modifying files on disk is not a great solution, which is one of the many good reasons @JakeGinnivan started on #1243 and #1244 for an in-memory model that could be modified without changing anything physically stored on the disk. I still believe the in-memory model is the way to go for this issue and many more, but it's a massive task to undertake which is why it hasn't been completed as of yet.

A short-term compromise would be to introduce a command line switch and MSBuild property that allows the normalization to be disabled. A PR for that with tests would be accepted and merged.

[JakeGinnivan]

I got stuck trying to figure out a good data structure which would answer all the questions GitVersion needs to ask of it in an effective way.

My plan was to try refactor the current code into a single interface with the specific questions of the git repo, like which branch does this ref come from. Or how many commits since the branch point etc.

After we had that, we could try to create the in memory model to support that interface. Then we could ship it behind a flag to test it out (have the two different modes). Then we could also populate that in memory model through the git CLI rather than libgit2, or even the github apis. It would make gitversion way more flexible

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.