[Bug] 5.6.5 Not finding Tag in master repo #2590

Eneuman · 2021-02-09T07:32:54Z

My master branch has a Tag 6.1.0.
It get correctly picked up by version 5.6.4

  INFO [01/28/21 13:53:18:60] Begin: Calculating base versions
    INFO [01/28/21 13:53:18:62] Fallback base version: 0.1.0 with commit count source 1f34f7b0477ebdaba3db9de21c9bc4aa1ba432d9
    INFO [01/28/21 13:53:18:67] Git tag '6.1.0': 6.1.0 with commit count source ee2c143847ae685ad96dedb7020bf563ac535bea
    INFO [01/28/21 13:53:18:72] Found multiple base versions which will produce the same SemVer (6.2.0), taking oldest source for commit counting (Git tag '6.1.0')
    INFO [01/28/21 13:53:18:72] Base version used: Git tag '6.1.0': 6.1.0 with commit count source ee2c143847ae685ad96dedb7020bf563ac535bea
  INFO [01/28/21 13:53:18:72] End: Calculating base versions (Took: 117.57ms)

but in version 5.6.5 it is not found:

INFO [02/09/21 7:24:04:69] Begin: Calculating base versions
    INFO [02/09/21 7:24:04:71] Fallback base version: 0.1.0 with commit count source 1f34f7b0477ebdaba3db9de21c9bc4aa1ba432d9
    INFO [02/09/21 7:24:04:80] Found multiple base versions which will produce the same SemVer (0.2.0), taking oldest source for commit counting (Fallback base version)
    INFO [02/09/21 7:24:04:80] Base version used: Fallback base version: 0.1.0 with commit count source 1f34f7b0477ebdaba3db9de21c9bc4aa1ba432d9
  INFO [02/09/21 7:24:04:80] End: Calculating base versions (Took: 118.04ms)

The text was updated successfully, but these errors were encountered:

luis-fss · 2021-02-09T14:39:02Z

I don't know if it's related, but I'm also getting strange behavior.
I believe that there is a bug between version 5.6.4 and 5.6.6 that causes an incorrect version to be calculated.

GitVersion 5.6.4 Behavior

INFO [02/09/21 11:17:14:53] Found multiple base versions which will produce the same SemVer (1.5.5), taking oldest source for commit counting (Git tag 'v1.5.4')

GitVersion 5.6.6 Behavior

INFO [02/09/21 11:20:45:54] Found multiple base versions which will produce the same SemVer (1.5.0), taking oldest source for commit counting (Git tag 'v1.4.10')

GitVersion.yml.txt

GitVersion-5.6.5.diagnostic.txt
GitVersion-5.6.6.diagnostic.txt
GitVersion-5.6.4.diagnostic.txt

arturcic · 2021-02-09T14:53:25Z

@gep13 might be related to your fix

gep13 · 2021-02-10T09:17:59Z

@Eneuman do you have a link to the project where this is occuring?

Eneuman · 2021-02-10T09:50:20Z

It's a private project but you can repo it this way:

On Azure Dev Ops create a git repo (branch name master).
Set a tag like 2.0.0
Create a pipeline and use the the gittools tasks to install latest gitversion and then calculate a new version.

Use default settings and run a build.

arturcic · 2021-02-10T09:51:59Z

Would be great to have a fixture test that reproduce the issue

Eneuman · 2021-02-10T09:54:03Z

I can also verify that going back to version 5.6.4 solves the problem so something have definitely changed.

gep13 · 2021-02-10T09:56:10Z

@Eneuman are you doing anything "extra" to download additional portions of the git repository? Or how is Azure DevOps performing the checkout of the git repostiory?

Having a complete Azure DevOps yml file for what you are doing would certainly help in figuring out the underlying issue.

A change was made in 5.6.5 to specifically address an issue where the incorrect version number was being asserted on a tagged commit when running on GitHub Actions, so it is possible that this change has had a negative impact when running on Azure DevOps, but in order to figure this out, we would need to complete set of steps to reproduce the problem.

Eneuman · 2021-02-10T10:03:52Z

@gep13 The yml file is very basic:

    - task: gitversion/setup@0
      displayName: GitVersion
      inputs:
        versionSpec: '5.6.6'
        includePrerelease: false

    - task: gitversion/execute@0
      displayName: GitVersion Execute
      inputs:
        useConfigFile: true
        configFilePath: 'GitVersion.yaml'

and the config file:

mode: Mainline
legacy-semver-padding: 3
build-metadata-padding: 3
commits-since-version-source-padding: 3
branches:
  develop:
    tag: preview
  master:
    tag: ''

My gut says this has something to do with the change from "master" to "main" (I diffed 5.6.4 with 5.6.6).
We are still using "master" as the name of our main branch.

gep13 · 2021-02-10T10:20:08Z

@Eneuman again to my point, in order to figure this out, we need complete details on how your repository is set up, so that we can start to investigate what is going on.

The ideal here, if possible, would be for you to setup a public repository, in a way that replicates the problem, and that way, we can start to attempt to figure out what is going on.

Is this something that you can help with?

Eneuman · 2021-02-10T13:00:35Z

@gep13 sure I can fix that.

I have setup a public repo at https://caresoftab.visualstudio.com/Test/_git/Test

The repo has 3 tags:

git tag reports this:
3.0.0
3.1.0
4.0.0

gitversion.exe /url https://caresoftab.visualstudio.com/Test/_git/Test /b master /nocache

{
  "Major": 3,
  "Minor": 0,
  "Patch": 1,
  "PreReleaseTag": "",
  "PreReleaseTagWithDash": "",
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": "",
  "WeightedPreReleaseNumber": 60000,
  "BuildMetaData": 1,
  "BuildMetaDataPadded": "0001",
  "FullBuildMetaData": "1.Branch.master.Sha.2b47dfd3facf4dae171d33e11da7990ac9704023",
  "MajorMinorPatch": "3.0.1",
  "SemVer": "3.0.1",
  "LegacySemVer": "3.0.1",
  "LegacySemVerPadded": "3.0.1",
  "AssemblySemVer": "3.0.1.0",
  "AssemblySemFileVer": "3.0.1.0",
  "FullSemVer": "3.0.1+1",
  "InformationalVersion": "3.0.1+1.Branch.master.Sha.2b47dfd3facf4dae171d33e11da7990ac9704023",
  "BranchName": "master",
  "EscapedBranchName": "master",
  "Sha": "2b47dfd3facf4dae171d33e11da7990ac9704023",
  "ShortSha": "2b47dfd",
  "NuGetVersionV2": "3.0.1",
  "NuGetVersion": "3.0.1",
  "NuGetPreReleaseTagV2": "",
  "NuGetPreReleaseTag": "",
  "VersionSourceSha": "bcff8056621e44685ecccead5e9db96e8458c62c",
  "CommitsSinceVersionSource": 1,
  "CommitsSinceVersionSourcePadded": "0001",
  "UncommittedChanges": 1,
  "CommitDate": "2021-02-10"
}

A quick analysis showed me that LibGit2Sharp tagcollection only contains the 3.0.0 tag.

arturcic · 2021-02-10T13:01:52Z

thank you for the sample, we'll have a look

arturcic · 2021-02-10T14:00:07Z

I ran the gitversion.exe /url https://caresoftab.visualstudio.com/Test/_git/Test /b master /nocache
and I got

{
  "Major": 4,
  "Minor": 0,
  "Patch": 1,
  "PreReleaseTag": "",
  "PreReleaseTagWithDash": "",
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": null,
  "WeightedPreReleaseNumber": 60000,
  "BuildMetaData": 1,
  "BuildMetaDataPadded": "0001",
  "FullBuildMetaData": "1.Branch.master.Sha.2b47dfd3facf4dae171d33e11da7990ac9704023",
  "MajorMinorPatch": "4.0.1",
  "SemVer": "4.0.1",
  "LegacySemVer": "4.0.1",
  "LegacySemVerPadded": "4.0.1",
  "AssemblySemVer": "4.0.1.0",
  "AssemblySemFileVer": "4.0.1.0",
  "FullSemVer": "4.0.1+1",
  "InformationalVersion": "4.0.1+1.Branch.master.Sha.2b47dfd3facf4dae171d33e11da7990ac9704023",
  "BranchName": "master",
  "EscapedBranchName": "master",
  "Sha": "2b47dfd3facf4dae171d33e11da7990ac9704023",
  "ShortSha": "2b47dfd",
  "NuGetVersionV2": "4.0.1",
  "NuGetVersion": "4.0.1",
  "NuGetPreReleaseTagV2": "",
  "NuGetPreReleaseTag": "",
  "VersionSourceSha": "bcff8056621e44685ecccead5e9db96e8458c62c",
  "CommitsSinceVersionSource": 1,
  "CommitsSinceVersionSourcePadded": "0001",
  "UncommittedChanges": 0,
  "CommitDate": "2021-02-10"
}

arturcic · 2021-02-10T14:00:41Z

I used version 5.6.6, locally

Eneuman · 2021-02-10T14:03:38Z

I added a new file and another tag 5.0.0

Can you try again now?

arturcic · 2021-02-10T14:05:52Z

I ran again same command

{
  "Major": 4,
  "Minor": 0,
  "Patch": 1,
  "PreReleaseTag": "",
  "PreReleaseTagWithDash": "",
  "PreReleaseLabel": "",
  "PreReleaseLabelWithDash": "",
  "PreReleaseNumber": null,
  "WeightedPreReleaseNumber": 60000,
  "BuildMetaData": 2,
  "BuildMetaDataPadded": "0002",
  "FullBuildMetaData": "2.Branch.master.Sha.3e83fa0cc5464862601e75f31c30881a687e21b7",
  "MajorMinorPatch": "4.0.1",
  "SemVer": "4.0.1",
  "LegacySemVer": "4.0.1",
  "LegacySemVerPadded": "4.0.1",
  "AssemblySemVer": "4.0.1.0",
  "AssemblySemFileVer": "4.0.1.0",
  "FullSemVer": "4.0.1+2",
  "InformationalVersion": "4.0.1+2.Branch.master.Sha.3e83fa0cc5464862601e75f31c30881a687e21b7",
  "BranchName": "master",
  "EscapedBranchName": "master",
  "Sha": "3e83fa0cc5464862601e75f31c30881a687e21b7",
  "ShortSha": "3e83fa0",
  "NuGetVersionV2": "4.0.1",
  "NuGetVersion": "4.0.1",
  "NuGetPreReleaseTagV2": "",
  "NuGetPreReleaseTag": "",
  "VersionSourceSha": "bcff8056621e44685ecccead5e9db96e8458c62c",
  "CommitsSinceVersionSource": 2,
  "CommitsSinceVersionSourcePadded": "0002",
  "UncommittedChanges": 1,
  "CommitDate": "2021-02-10"
}

arturcic · 2021-02-10T14:06:53Z

So it does not see the 5.0.0 tag

Eneuman · 2021-02-10T14:07:23Z

Yeah, that's the bug. Should'nt you have revived 5.0.1?

Eneuman · 2021-02-10T14:07:51Z

Try git tag

arturcic · 2021-02-10T14:11:51Z

git tag returns

3.0.0
3.1.0
4.0.0

arturcic · 2021-02-10T14:14:42Z

I think I know the reason. When you run giversion in a dynamic way (by specifying url and branch) it clones the repository to temp location (C:\Users{user}\AppData\Local\Temp{repo}). That means when you run the same command the second time it will use the same path, and if you add new tags on the remote origin, and run the command it will not update your local copy in the temp folder, it will use the outdated repository. After I deleted the temp folder and ran the command again, it returned the correct version

Eneuman · 2021-02-10T14:16:38Z

Can the same thing happen when running in a pipeline using the gitversion task?

arturcic · 2021-02-10T14:18:11Z

If that is on premise agent I guess it might have the same issue

Eneuman · 2021-02-10T14:20:18Z

Is there a argument that will run git fetch on a existing dynamic repo when running gitversion?

arturcic · 2021-02-10T14:23:03Z

you can run the git fetch command, but I would suggest not to use dynamic repo, as we plan to remove the support for it

Eneuman · 2021-02-10T14:47:38Z

I tried again (in my private project) using the task in the yaml pipeline but it still calculates the wrong version.

Init task:

Starting: GitVersion
==============================================================================
Task         : Setup GitVersion Task
Description  : Easy Semantic Versioning (http://semver.org) for projects using Git
Version      : 0.9.9
Author       : GitTools Contributors
Help         : See the [documentation](https://gitversion.net/docs/) for help
==============================================================================

--------------------------
Installing GitVersion.Tool version 5.6.5
--------------------------
Command: dotnet tool install GitVersion.Tool --tool-path D:\a\_temp --version 5.6.5
"C:\Program Files\dotnet\dotnet.exe" tool install GitVersion.Tool --tool-path D:\a\_temp --version 5.6.5
You can invoke the tool using the following command: dotnet-gitversion
Tool 'gitversion.tool' (version '5.6.5') was successfully installed.
Caching tool: GitVersion.Tool 5.6.5 x64
Prepending PATH environment variable with directory: C:\hostedtoolcache\windows\GitVersion.Tool\5.6.5\x64
Finishing: GitVersion

Execute:

==============================================================================
Task         : Execute GitVersion Task
Description  : Easy Semantic Versioning (http://semver.org) for projects using Git
Version      : 0.9.9
Author       : GitTools Contributors
Help         : See the [documentation](https://gitversion.net/docs/) for help
==============================================================================
Command: dotnet-gitversion D:/a/1/s /output json /output buildserver /config D:\a\1\s\GitVersion.yaml
C:\hostedtoolcache\windows\GitVersion.Tool\5.6.5\x64\dotnet-gitversion.exe D:/a/1/s /output json /output buildserver /config D:\a\1\s\GitVersion.yaml
INFO [02/10/21 10:24:24:28] Working directory: D:/a/1/s
INFO [02/10/21 10:24:24:36] Branch from build environment: refs/heads/develop
INFO [02/10/21 10:24:24:36] Project root is: D:\a\1\s\
INFO [02/10/21 10:24:24:36] DotGit directory is: D:\a\1\s\.git
INFO [02/10/21 10:24:24:36] Begin: Normalizing git directory for branch 'refs/heads/develop'
  INFO [02/10/21 10:24:24:42] One remote found (origin -> 'https://caresoftab.visualstudio.com/eClinic/_git/eClinic_MicroService').
  INFO [02/10/21 10:24:24:43] Skipping fetching, if GitVersion does not calculate your version as expected you might need to allow fetching or use dynamic repositories
  INFO [02/10/21 10:24:24:44] Creating local branch develop
  INFO [02/10/21 10:24:24:48] Creating local branch from remote tracking 'refs/remotes/origin/ff516009fbb23325de6ec7e66db2ba5c5cbab1c8'.
  INFO [02/10/21 10:24:24:50] Creating local branch from remote tracking 'refs/remotes/origin/master'.
  INFO [02/10/21 10:24:24:50] HEAD points at branch 'refs/heads/develop'.
  INFO [02/10/21 10:24:24:51] End: Normalizing git directory for branch 'refs/heads/develop' (Took: 147.10ms)
  INFO [02/10/21 10:24:24:53] Begin: Loading version variables from disk cache
    INFO [02/10/21 10:24:24:54] Cache file D:\a\1\s\.git\gitversion_cache\1CBBFDF172BD2C9689F832B3A1B47B17D8EDFB5D.yml not found.
  INFO [02/10/21 10:24:24:54] End: Loading version variables from disk cache (Took: 8.46ms)
  INFO [02/10/21 10:24:24:92] Using latest commit on specified branch
  INFO [02/10/21 10:24:24:96] Running against branch: develop (ff51600 Fix)
  INFO [02/10/21 10:24:24:97] Begin: Calculating base versions
    INFO [02/10/21 10:24:24:99] Fallback base version: 0.1.0 with commit count source 1f34f7b0477ebdaba3db9de21c9bc4aa1ba432d9
    INFO [02/10/21 10:24:25:07] Found multiple base versions which will produce the same SemVer (0.2.0), taking oldest source for commit counting (Fallback base version)
    INFO [02/10/21 10:24:25:07] Base version used: Fallback base version: 0.1.0 with commit count source 1f34f7b0477ebdaba3db9de21c9bc4aa1ba432d9
  INFO [02/10/21 10:24:25:07] End: Calculating base versions (Took: 109.30ms)

Running dotnet-gitversion in my local repo do return the correct version.

What do I need to do to debug the gitversion code against a local repo?
I got the fork and can debug against my testproject but it then uses a dynamic repo and I want it to use my local repo.
Setting the working directory does not seem to work.

arturcic · 2021-02-10T15:19:01Z

INFO [02/10/21 10:24:24:43] Skipping fetching, if GitVersion does not calculate your version as expected you might need to allow fetching seems like it's skipping fetching and that is because the AzurePipelines agent is configured to skip fetching as it does the fetching itself. You need to check why your agent is not fetching all the tags

Eneuman · 2021-02-10T15:28:55Z

Checking the log it looks okey I think:

From https://caresoftab.visualstudio.com/eClinic/_git/eClinic_MicroService
 * [new branch]      develop    -> origin/develop
 * [new branch]      master     -> origin/master
 * [new tag]         6.1.0      -> 6.1.0
 * [new tag]         6.2.0      -> 6.2.0
git -c http.extraheader="AUTHORIZATION: XXXXX" fetch --force --tags --prune --progress --no-recurse-submodules origin +ff516009fbb23325de6ec7e66db2ba5c5cbab1c8:refs/remotes/origin/ff516009fbb23325de6ec7e66db2ba5c5cbab1c8

From https://caresoftab.visualstudio.com/eClinic/_git/eClinic_MicroService
 * [new ref]         ff516009fbb23325de6ec7e66db2ba5c5cbab1c8 -> origin/ff516009fbb23325de6ec7e66db2ba5c5cbab1c8
git checkout --progress --force ff516009fbb23325de6ec7e66db2ba5c5cbab1c8

and if I switch back to version 5.6.4 it works.

Eneuman · 2021-02-10T15:47:41Z

I can see now that this line is logged when it it working, but not when the version gets calculated wrong.

INFO [02/10/21 10:24:24:42] One remote found (origin -> 'https://caresoftab.visualstudio.com/eClinic/_git/eClinic_MicroService').

so maby it's not finding my remote repo and thats why it doesn't find my tags.

luis-fss · 2021-02-10T17:59:20Z

As I said before, I don't know if I'm facing the same problem, but it seems so...
I just created an example repository and here are the necessary steps to reproduce the problem, please @gep13 or @arturcic take a look when you can:

git clone https://github.com/Lukkian/GitVersionTest.git
git checkout develop
dotnet tool install --global GitVersion.Tool --version 5.6.4
dotnet-gitversion
Observe that "SemVer" should be "SemVer": "1.5.1-beta.1"
dotnet tool update --global GitVersion.Tool --version 5.6.6
Important! Delete the folder .git\gitversion_cache
dotnet-gitversion
Observe that "SemVer" now is "SemVer": "1.1.2-beta.4", it should be the same as in step 5: "SemVer": "1.5.1-beta.1"

arturcic · 2021-02-10T18:01:36Z

As I said before, I don't know if I'm facing the same problem, but it seems so.
I just created an example repository and here are the necessary steps to reproduce the problem, please @gep13 or @arturcic take a look when you can:

git clone https://github.com/Lukkian/GitVersionTest.git

git checkout develop

dotnet tool install --global GitVersion.Tool --version 5.6.4

dotnet-gitversion

Observe that "SemVer" should be "SemVer": "1.5.1-beta.1"

dotnet tool update --global GitVersion.Tool --version 5.6.6

Imporant! Delete the folder .git\gitversion_cache

dotnet-gitversion

Observe that "SemVer" now is "SemVer": "1.1.2-beta.4", it should be the same as in step 5: "SemVer": "1.5.1-beta.1"

Thanks for the steps @Lukkian we'll have a look

arturcic · 2021-02-11T06:49:18Z

@Lukkian I can confirm the issue. Need to investigate

asbjornu · 2021-02-11T09:05:13Z

Could this be related to the move from master to main somehow? What happens if you rename master to main, @Lukkian?

luis-fss · 2021-02-11T12:34:03Z

Yes @asbjornu, after renaming master to main, GitVersion.Tool in both versions 5.6.4 and 5.6.6 correctly produces the version of the repository as expected: "SemVer": "1.5.1-beta.1"

The curious thing is that the configuration file has the instruction below
(which does not seem to be honored by GitVersion 5.6.6):

master:
    regex: ^master$|^main$

FYI: I did the tests only locally and did not push, so if you want to test, the remote repo has not been changed.

arturcic · 2021-02-11T12:35:34Z

@Lukkian thanks for the update. I will check what missing piece was not updated. Please do not change the remote

luis-fss · 2021-04-29T14:30:39Z

Hey @arturcic, sorry to bother you...
Do you think this issue could be fixed in next version?

nathangiuliani · 2021-06-08T00:13:10Z

This issues has forced us to leave gitversion on 5.6.4 for all of our projects that utilise it. I can only assume that it doesn't impact everyone, or it would have been given a higher priority. Does anyone know what the root cause is?

asbjornu · 2021-06-08T09:06:01Z

@nathangiuliani,

This issues has forced us to leave gitversion on 5.6.4 for all of our projects that utilise it.

That's unfortunate. 😞

I can only assume that it doesn't impact everyone, or it would have been given a higher priority.

Correct.

Does anyone know what the root cause is?

No, but @Lukkian has provided a reproduction in #2590 (comment). What's required is for someone with proper incentive and time to execute a local source build of GitVersion against that repository and through breakpoints or other debugging figure out where and what's causing the exception.

Then the bug needs to be fixed and submitted as a pull request.

lbras · 2021-10-01T10:29:30Z

Hello! New user of GitVersion here and it seems like I also stumbled into this issue. I understand this is not a high priority, but I just want to leave another example repository with the steps to reproduce the problem. Using #2590 (comment) as a template:

git clone https://github.com/lbras/GitVersionTests-bug-2590.git
git checkout develop
dotnet tool install --global GitVersion.Tool --version 5.6.4
dotnet-gitversion
Observe that "SemVer" should be "SemVer": "2.1.0-alpha.2"
dotnet tool update --global GitVersion.Tool --version 5.6.5
Important! Delete the folder .git\gitversion_cache
dotnet-gitversion
Observe that "SemVer" now is "SemVer": "1.1.0-alpha.4", it should be the same as in step 5: "SemVer": "2.1.0-alpha.2"

Repository graph:

The same behavior happens with version 5.7.0. I'll continue using version 5.6.4 for now.

lbras · 2021-10-01T10:37:10Z

I compiled GitVersion from source and run a git bisect on it between versions 5.6.4 and 5.6.5. The bug appears to have been introduced in commit 8b653e9:

8b653e9f75cae9c9918a148de23864feaae736f1 is the first bad commit
commit 8b653e9f75cae9c9918a148de23864feaae736f1
Author: Artur 
Date:   Sun Jan 31 12:14:26 2021 +0100

    changed the default branch from master to main

lbras · 2021-10-01T11:35:18Z

Took a quick look at the code and found the following. Updating line 53 from TrackReleaseBranchesVersionStrategy.cs (MainTagsVersions method) from

var main = this.repositoryStore.FindBranch(Config.MainBranchKey);

to

var main = this.repositoryStore.FindBranch(Config.MainBranchKey);
if (main == null)
{
	// for compatibility reason try to find master if main cannot be found
	main = this.repositoryStore.FindBranch(Config.MasterBranchKey);
}

solves the issue. Now, I'm not familiar with the codebase at all and have no idea of any side effects, but it keeps all existing tests passing.

Any advice on this? @asbjornu @arturcic

asbjornu · 2021-10-01T12:02:46Z

@lbras, fantastic debugging! If changing from MainBranchKey to MasterBranchKey fixes the issue, I'm wondering whether this bug may be lurking elsewhere in the codebase as well. Perhaps the simplest fix would be for Config.MainBranchKey to return the value of Config.MasterBranchKey if the former is null? With a fix in place, you're welcome to submit a PR, perhaps in draft state, so we can discuss how to progress it.

superjulius · 2022-03-01T11:31:53Z

We are looking to replace the deprecated GitVersion with the latest GitTools task in Azure Pipelines but we also hit the versioning issue as our repo is using master naming

@asbjornu @arturcic Is it safe to explicitly target 5.6.4 (no risk of depreciation)? Is there any plan to fix this in 5.x? or more likely to be addressed in 6.x?

asbjornu · 2022-03-01T14:34:46Z

Already published versions of the GitTools task should continue to work, @superjulius. If they are removed, that's beyond our control and up to Microsoft, if anything. There is no plan to fix this beyond us accepting a pull request that fixes it. As none of the maintainers seem to have this issue, we have no incentive to work on it, unfortunately.

Fall back to `master` if `main` is missing. Fixes GitToolsGH-2590.

asbjornu · 2022-03-08T20:47:45Z

I've submitted #3037 based on @Ibras' suggestions. If you can think of a way to reproduce the issue in a test, I'd be very grateful. If not, I think the fix is worth merging even without a regression test.

Fall back to `master` if `main` is missing. Fixes GitToolsGH-2590.

Fall back to `master` if `main` is missing

github-actions · 2022-04-14T07:33:42Z

🎉 This issue has been resolved in version 5.10.0 🎉
The release is available on:

Your GitReleaseManager bot 📦🚀

Eneuman added the bug label Feb 9, 2021

luis-fss mentioned this issue Feb 9, 2021

Segmentation fault in 3.1 docker image #2308

Closed

Eneuman changed the title ~~[Bug] 5.6.6 Not finding Tag in master repo~~ [Bug] 5.6.5 Not finding Tag in master repo Feb 10, 2021

arturcic self-assigned this Feb 25, 2021

dbarentine mentioned this issue Jul 30, 2021

[Bug] Not finding tags in master #2792

Closed

asbjornu mentioned this issue Mar 2, 2022

Base version calculation failed since 5.6.5 #2801

Closed

asbjornu added a commit to asbjornu/GitVersion that referenced this issue Mar 8, 2022

Fall back to master if main is missing

10e81a1

Fall back to `master` if `main` is missing. Fixes GitToolsGH-2590.

asbjornu mentioned this issue Mar 8, 2022

Fall back to master if main is missing #3037

Merged

5 tasks

asbjornu added a commit to asbjornu/GitVersion that referenced this issue Mar 9, 2022

Fall back to master if main is missing

62377fc

Fall back to `master` if `main` is missing. Fixes GitToolsGH-2590.

asbjornu added a commit to asbjornu/GitVersion that referenced this issue Apr 12, 2022

Fall back to master if main is missing

90d5e6a

Fall back to `master` if `main` is missing. Fixes GitToolsGH-2590.

asbjornu closed this as completed in #3037 Apr 13, 2022

asbjornu added a commit that referenced this issue Apr 13, 2022

Merge pull request #3037 from asbjornu/feature/gh-2590

3892733

Fall back to `master` if `main` is missing

asbjornu added this to the 5.x milestone Apr 13, 2022

arturcic modified the milestones: 5.x, 5.10.0 Apr 14, 2022

[Bug] 5.6.5 Not finding Tag in master repo #2590

[Bug] 5.6.5 Not finding Tag in master repo #2590

Comments

Eneuman commented Feb 9, 2021 • edited Loading

luis-fss commented Feb 9, 2021

GitVersion 5.6.4 Behavior

GitVersion 5.6.6 Behavior

arturcic commented Feb 9, 2021

gep13 commented Feb 10, 2021

Eneuman commented Feb 10, 2021

arturcic commented Feb 10, 2021

Eneuman commented Feb 10, 2021

gep13 commented Feb 10, 2021

Eneuman commented Feb 10, 2021 • edited Loading

gep13 commented Feb 10, 2021

Eneuman commented Feb 10, 2021 • edited Loading

arturcic commented Feb 10, 2021

arturcic commented Feb 10, 2021

arturcic commented Feb 10, 2021

Eneuman commented Feb 10, 2021

arturcic commented Feb 10, 2021

arturcic commented Feb 10, 2021

Eneuman commented Feb 10, 2021 • edited Loading

Eneuman commented Feb 10, 2021

arturcic commented Feb 10, 2021

arturcic commented Feb 10, 2021 • edited Loading

Eneuman commented Feb 10, 2021

arturcic commented Feb 10, 2021

Eneuman commented Feb 10, 2021 • edited Loading

arturcic commented Feb 10, 2021

Eneuman commented Feb 10, 2021 • edited Loading

arturcic commented Feb 10, 2021

Eneuman commented Feb 10, 2021

Eneuman commented Feb 10, 2021 • edited Loading

luis-fss commented Feb 10, 2021 • edited Loading

arturcic commented Feb 10, 2021

arturcic commented Feb 11, 2021

asbjornu commented Feb 11, 2021

luis-fss commented Feb 11, 2021 • edited Loading

arturcic commented Feb 11, 2021

luis-fss commented Apr 29, 2021

nathangiuliani commented Jun 8, 2021

asbjornu commented Jun 8, 2021 • edited Loading

lbras commented Oct 1, 2021 • edited Loading

lbras commented Oct 1, 2021

lbras commented Oct 1, 2021

asbjornu commented Oct 1, 2021

superjulius commented Mar 1, 2022

asbjornu commented Mar 1, 2022

asbjornu commented Mar 8, 2022

github-actions bot commented Apr 14, 2022

Eneuman commented Feb 9, 2021 •

edited

Loading

Eneuman commented Feb 10, 2021 •

edited

Loading

Eneuman commented Feb 10, 2021 •

edited

Loading

Eneuman commented Feb 10, 2021 •

edited

Loading

arturcic commented Feb 10, 2021 •

edited

Loading

Eneuman commented Feb 10, 2021 •

edited

Loading

Eneuman commented Feb 10, 2021 •

edited

Loading

Eneuman commented Feb 10, 2021 •

edited

Loading

luis-fss commented Feb 10, 2021 •

edited

Loading

luis-fss commented Feb 11, 2021 •

edited

Loading

asbjornu commented Jun 8, 2021 •

edited

Loading

lbras commented Oct 1, 2021 •

edited

Loading