GitVersion creates branch named after SHA1

[xlegalles]

I first thought it was a TeamCity bug but it may not: in one single repository from 15, we always get a report from GitVersion that uses a commit sha as the branch name i.e. a detached head. I simply added a "git branch" step before and after the gitversion one and I have to admit the evidence

• before I get "develop"
• the GitVersion reports a current branch 3427875e403aa2b52ea983528e765c22c17ab41a
• after I get effectively "3427875e403aa2b52ea983528e765c22c17ab41a"
  So, yes, before GitVersion we have the right branch but as soon as GitVersion is executed, we get a detached head.
  Of course, I have traced the vcs logs from TeamCity and there is nothing but a normal checkout of the current branch (i.e. develop)

Any idea?

[asbjornu]

@xlegalles: Can you reproduce this outside of the specific repository, make the repository public or otherwise share something that can be debugged? Are you using GitVersionTask or gitversion.exe? Which version of GitVersion are you using; 3.x or 4.x?

[xlegalles]

We use Gitversion.exe v3.6.4.0 installed by Chocolatey.
I Cannot make the repo public :( I have attached the TC logs where you can see the first 'git branch' (good), then gitversion (wrong) and the next 'git branch' (wrong)

Of course, I can try anything you want but for instance, I don't see any way to debug what is doing GitVersion? Is it even possible that it could change the current git branch?
build.txt

[JakeGinnivan]

What have you set Git_Branch to in the teamcity build parameters? Maybe it was mapped wrong?

[xlegalles]

The VCS root ID is KappaAutomate_TaskFilteringGit and the env.Git_Branch is set to %build.vcs.number.KappaAutomate_TaskFilteringGit% which seems right...

[pavlovps]

@xlegalles do you have "Use mirrors" in your VCS root settings? If yes then I would suggest removing it and trying again. Besides, there should be a parameter teamcity.git.fetchAllHeads = true which fixes another issue but then again why not to try.

[xlegalles]

Sorry but it does not change anything...

[xlegalles]

Just upgraded our server to 2017.1.2 (build 46812) and still the same issue

[asbjornu]

@xlegalles: Have you tried adding the configuration parameter teamcity.git.fetchAllHeads to the project and when set it to true? Then TeamCity should fetch all branches and not just the current one.

[xlegalles]

@pavlovps already proposed this option that I have tried without any success...

[asbjornu]

@xlegalles: Yea, he had two suggestions, though, so I didn't know which one of them you tried. 😕

[asbjornu]

@xlegalles: I just had a similar problem in a repository. The repository is not in a detached head state, though; the problem is that GitVersion (most probably -- what else?) has created a branch named after the commit id. Bizarre! Just look at this:

> git branch
* 3a1fb0a6803ea9ed52313f7ec47ca25c726203c4
  develop
  master
  release/2.0.1

Can @JakeGinnivan provide any insight into why on earth this might be happening? Is it even possible that GitVersion is creating a branch?

[xlegalles]

@asbjornu I thought it was a detached head because it looks like. But you may be right. The thing is that I am quite sure that Gitversion is responsible for that and it's really weird.

[asbjornu]

@xlegalles: I'm pretty sure GitRepositoryHelper.NormalizeGitDirectory() is to blame:

https://github.com/GitTools/GitTools.Core/blob/master/src/GitTools.Core/Git/Helpers/GitRepositoryHelper.cs#L21

But I need to investigate further to figure this one out. I'm currently a bit stumped by GitTools.Core being converted to Visual Studio 2017 project format, so I can't get a debug build out of it on my machine. @dazinator halp pl0x? 😄