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? 😄

[dazinator]

@asbjornu - haha, yeah sorry, the solution was updated to vs2017 and the project uses the new sdk style csproj format which allows you to build for multiple target frameworks more easily: https://github.com/GitTools/GitTools.Core/blob/master/src/GitTools.Core/GitTools.Core.csproj#L5 - which became relevant when adding support for netstandard to unlock support for other platforms such as netcoreapp.

Is there anything I can do to help? I think you might have to open with VS2017 community..!

[asbjornu]

@dazinator: I figured it out, thanks.

@xlegalles: I believe I have found the problem:

https://github.com/GitTools/GitTools.Core/blob/90add8fe4793a09400b538b95ca84458cc495441/src/GitTools.Core/Git/Helpers/GitRepositoryHelper.cs#L155-L161

if (repo.Branches.All(b => b.CanonicalName != localCanonicalName))
{
    Log.Info(isBranch ?
        string.Format("Creating local branch {0}", localCanonicalName) :
        string.Format("Creating local branch {0} pointing at {1}", localCanonicalName, repoTipId));
    repo.Refs.Add(localCanonicalName, repoTipId);
}

In my testing, this ends up with the following line logged:

Creating local branch refs/heads/3a1fb0a6803ea9ed52313f7ec47ca25c726203c4 pointing at 3a1fb0a6803ea9ed52313f7ec47ca25c726203c4

I have no idea in which context this is the correct behaviour. I need to dig deeper and understand why that code exists.

[xlegalles]

@asbjornu thtat's great news. I'm still convinced that GitVersion should never create a branch because we all see it as a read-only tool i.e. it's main goal is to give information and never to modify the current Git state.
Also if you find a workaround or if you can explain why it can happen with a repo and not others, it could be usefull ;)

[asbjornu]

Found it. The EnsureLocalBranchExistsForCurrentBranch method was added in 3191611 by @JakeGinnivan and merged in #571. Given the size of that commit and the generic commit message, it's impossible for me to deduce why it was added.

My suggestion would be to fiddle with this part of the code (especially repo.Refs.Add(localCanonicalName, repo.Head.Tip.Id);) and see what tests break. What makes that a bit hard is that the tests that exercise the code exist in the GitVersion codebase, while the GitRepositoryHelper (nèe GitHelper) has been moved to GitTools.Core.

Does @gep13 have ideas on how to tackle this?

[xlegalles]

Any news? Thank you

[xlegalles]

FYI, this pb is so annoying that I have decided to recreate the Git repo from scratch. Because since then , we have created other repositories which do not have any problem i.e. this one was still the only one to have a trouble. Believe it or not but it did not change anything! Even wo any Git history we have always the same error :(
So finally, I have tried to recreate the repo with a new name... and it works!
Would it be possible that it is related to the repo's name? It was task.filtering and is now process.filtering... Silly.

[asbjornu]

@xlegalles: I'm really sorry we haven't been of more help to you so far. This is a really obscure bug that I'm struggling with even understanding, so I'm struggling even more with how I'm going to fix it. We might just attempt removing the bad code, but as it lives in another repository with fewer tests, we will have to create a new pre-release NuGet package, upgrade it in this repository and then continue with that until the bug is fixed and all other tests are still green. And to the bug itself, I'm also stumped for ideas on how to reproduce it in an actual test. I'm open to ideas!

[xlegalles]

Also, don't forget what I have already told: GitVersion is not supposed to mutate anything from a Git point of view. This is very disturbing and that's why I first opened a ticket in TeamCity: I could not imagine that this tool was the cause of my problem.
Also I don't know how I can help you because locally, I cannot reproduce the problem with my repository archive...

[asbjornu]

I was able to reproduce locally by running GitVersion with the environment variable TEAMCITY_VERSION defined.

[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.