GitVersion 5.0.1 resolves wrong commit count after merge based on wrong VersionSourceSha #1830
Comments
|
Are you able to express the problem you're seeing as a |
|
I think I have the same issue. gv -diag option output:
Take a look at the line But on one previous line I see different commit count source. General observation: if I use git flow commands for release branch end I see wrong behaviour, if I follow git flow manually for the same release branch end I see correct commint count source. History looks different it these two cases. You can see tag v.12.0.0 was created using git flow extension. Tag v.11.0.0 was created manually. |
|
Are you able to reproduce this problem in a |
|
I'm having the same issues since I upgraded to the latest version. VersionSource doesn't seem to be set correctly. After merging a release, it should use this commit as the version source until another release will be made.
|
|
Until someone are able to reproduce this in a |
|
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. |
|
Is this still a problem in GitVersion 5.2.4? |
|
Yes. I've just checked and the issue is still presented. I shared a repo to see this issue https://[email protected]/newegor/testrepo.git |
|
@newegor, When running GitVersion on that repository, I get the following: {
"Major":12,
"Minor":0,
"Patch":0,
"PreReleaseTag":"",
"PreReleaseTagWithDash":"",
"PreReleaseLabel":"",
"PreReleaseNumber":"",
"WeightedPreReleaseNumber":"",
"BuildMetaData":5,
"BuildMetaDataPadded":"0005",
"FullBuildMetaData":"5.Branch.master.Sha.651959ac5b7fafc9ee45faad3ea5db14135f5cb7",
"MajorMinorPatch":"12.0.0",
"SemVer":"12.0.0",
"LegacySemVer":"12.0.0",
"LegacySemVerPadded":"12.0.0",
"AssemblySemVer":"12.0.0.0",
"AssemblySemFileVer":"12.0.0.0",
"FullSemVer":"12.0.0+5",
"InformationalVersion":"12.0.0+5.Branch.master.Sha.651959ac5b7fafc9ee45faad3ea5db14135f5cb7",
"BranchName":"master",
"Sha":"651959ac5b7fafc9ee45faad3ea5db14135f5cb7",
"ShortSha":"651959a",
"NuGetVersionV2":"12.0.0",
"NuGetVersion":"12.0.0",
"NuGetPreReleaseTagV2":"",
"NuGetPreReleaseTag":"",
"VersionSourceSha":"c6ab3b4eee5136be4e196d2fc974ddf5268e3fb1",
"CommitsSinceVersionSource":5,
"CommitsSinceVersionSourcePadded":"0005",
"CommitDate":"2019-11-16"
}I agree that |
|
If I add a tag to the $ git tag 12.0.0
$ gitversion
{
"Major":12,
"Minor":0,
"Patch":0,
"PreReleaseTag":"",
"PreReleaseTagWithDash":"",
"PreReleaseLabel":"",
"PreReleaseNumber":"",
"WeightedPreReleaseNumber":"",
"BuildMetaData":"",
"BuildMetaDataPadded":"",
"FullBuildMetaData":"Branch.master.Sha.651959ac5b7fafc9ee45faad3ea5db14135f5cb7",
"MajorMinorPatch":"12.0.0",
"SemVer":"12.0.0",
"LegacySemVer":"12.0.0",
"LegacySemVerPadded":"12.0.0",
"AssemblySemVer":"12.0.0.0",
"AssemblySemFileVer":"12.0.0.0",
"FullSemVer":"12.0.0",
"InformationalVersion":"12.0.0+Branch.master.Sha.651959ac5b7fafc9ee45faad3ea5db14135f5cb7",
"BranchName":"master",
"Sha":"651959ac5b7fafc9ee45faad3ea5db14135f5cb7",
"ShortSha":"651959a",
"NuGetVersionV2":"12.0.0",
"NuGetVersion":"12.0.0",
"NuGetPreReleaseTagV2":"",
"NuGetPreReleaseTag":"",
"VersionSourceSha":"651959ac5b7fafc9ee45faad3ea5db14135f5cb7",
"CommitsSinceVersionSource":5,
"CommitsSinceVersionSourcePadded":"0005",
"CommitDate":"2019-11-16"
} |
|
There is something about version source that seems wonky. I'm not sure what, why or how to fix it. |
|
As I wrote before there is a difference in the way of merging branches in case of wrong and right behaviour of GitVersion. On the screenshot attached v12 is a wrong case, v11 is right one. |
|
Well, by that description v11 is the correct according to Gitflow and v12 is wrong, so perhaps the "wrong" version calculation for v12 is actually correct? |
|
v12 was done by official git flow extension so I think it's correct. v11 was done manually. Technically results for v11 and for v12 are the same, so the version also should be the same. |
|
Which official Gitflow extension? From the descriptions of Gitflow I've read, release branches are merged to both
Thus, a merge from |
|
Please take a look to https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow and https://github.com/nvie/gitflow from the author of successful Git branching model |
|
Yes, @newegor, my quote is from that Atlassian article. I linked to it too. Here's a cheat sheet for
I'm not using any tooling for Git flow, I just do the process manually, but I've never seen or read anywhere that the |
|
I use git-flow from command line (it simplifies this process for me a lot). The same git-flow extention is used inside SourceTree from Atlassian (same result from the history point of view). But anyway I'd like to point that the base for "CommitsSinceVersionSource" calculation is wrong in case of git-flow usage from command line or any GUI tool. |
|
Ok, thanks for the information, @newegor. I doubt this is going to be fixed unless anyone experiencing this problem provide a pull request. Consider this an open invitation to everyone commenting on this issue to submit a PR that fixes the problem. :) |
|
Information provided in #2206 makes me believe that the implementation of |
|
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. |
Not sure how recently, but when I look back into our project it has been like this since the beginning (2018) when using SourceTree GitFlow tools. So bottom line is, that GitVersion does not support GitFlow currently? And the problematic part in fixing this would be to support both approaches
|
In all documentation I've read on Git Flow, the tag occurs on Whether GitVersion is compatible with some tools implementation of Git Flow is a different question and it seems like some tools that have changed their behaviour are no longer compatible with GitVersion's implementation. So yes, it's going to be hard to figure out how to solve this. It should be possible to detect the difference, it's just going to require a PR from someone who uses these Git Flow tools to fix it. I don't use tooling for Git Flow, so I don't have this problem, therefore I don't have much incentive to fix this myself. :) |
|
@asbjornu you are correct. After delving into this, I'm baffled why these tools actually do it so different from the GitFlow documentation. Personally I've always resorted on these so the actual flow was unknown to me. I also seem to actually get this with older GitVersion as well. The weird thing is that this happens at random, sometimes we get correct result and sometimes the source commit shifts. It looks like this is not actually an issue with the flow, but might have something to do with simultaneous commits. Commits created (by SourceTree GitFlow tooling in our case) actually have the exact same timestamp as per example below. Even 'git log' outputs them in the wrong order here. This seems to repro with the tool almost consistently if I create the release with no additional direct commits on the release branch itself.
Git log (default descending order): This could cause issues in this block of code, if the order of commits resolved from injection may have variaton. BaseVersionCalculator.cs I tried to repro this as unit test, but it will take more time with my non-existent knowledge of GitVersion codebase. Hopefully I can come back with this later. I suppose we would then need to implement some (uglyish) sniffing logic and make assumptions on the order of things to be consistent with the VersionSourceSha. Dunno 😵 Any thoughts on this? |
|
Thanks for the investigation, @AlexEngblom! If you are able to reproduce this in a physical Git repository (it seems like you are) and it proves hard to replicate the problem in a |
|
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. |
|
This issue is revived in #2394. |
After merging new release with related tag to master to development, GitVersion resolves way too big commit count. This issue seems to be that for some reason the previous release commit to master branch was used as VersionSource,
We noticed this because for whatever reasons, one of our build agents resolved the numbering properly (however the base version was resolved to merge tag commit instead of merge branch commit!), thus we ended up with mixed version incrementation.
Deleting the .git/gitversion-cache didn't help.
Downgrading to 4.0.0 fixed the issues.
GitVersion information:
5.0.1+Branch.master.Sha.c71b8fc9f6d7b6adffe82fef588e717beb864e91
GitVersion diag from 5.0.1:
INFO [09/27/19 8:50:21:67] Found multiple base versions which will produce the same SemVer (1.9.0), taking oldest source for commit counting (Merge message 'Merge branch 'release/1.8.0'')
INFO [09/27/19 8:50:21:68] Base version used: Merge message 'Merge branch 'release/1.8.0'': 1.8.0 with commit count source c81b4597a898cc49806f8e57d8e60df7bc1c82db (Incremented: 1.9.0)
INFO [09/27/19 8:50:21:69] End: Calculating base versions (Took: 2,404.09ms)
INFO [09/27/19 8:50:21:71] 64 commits found between c81b4597a898cc49806f8e57d8e60df7bc1c82db and 7c0742d94ec4c1da00d690ad0b93fadc43f14cdc
GitVersion diag from 4.0.0:
INFO [09/27/19 8:46:26:79] Found multiple base versions which will produce the same SemVer (1.9.0), taking oldest source for commit counting (Merge message 'Merge branch 'release/1.8.0'')
INFO [09/27/19 8:46:26:80] Base version used: Merge message 'Merge branch 'release/1.8.0'': 1.8.0 with commit count source f0351a3d24578e6bb42e0f0ad81bf259c25b07d4 (Incremented: 1.9.0)
INFO [09/27/19 8:46:26:80] End: Calculating base versions (Took: 3,701.51ms)
INFO [09/27/19 8:46:26:81] 11 commits found between f0351a3d24578e6bb42e0f0ad81bf259c25b07d4 and 7c0742d94ec4c1da00d690ad0b93fadc43f14cdc
Related merge commits:
commit d096c0432e7c54b67c8b06ac2b445acd004237e9
Merge: baff1bb f0351a3
Date: Tue Sep 24 10:13:21 2019 +0300
Merge tag '1.8.0' into development
1.8.0
commit f0351a3d24578e6bb42e0f0ad81bf259c25b07d4 (tag: 1.8.0)
Merge: c81b459 baff1bb
Date: Tue Sep 24 10:13:19 2019 +0300
Merge branch 'release/1.8.0'
The text was updated successfully, but these errors were encountered: