FWIW, there are actually two other similar calls to Reverse().

• MasterVersionFinder.cs(16)
• VersionOnMasterFinder.cs(18)

I haven't updated them because I'm not sure to understand the underlying expectations.

Provided there's only one tag in the repo named 1.0.2-Beta1, should it be considered by the calls in FindVersion() and Execute() and respectively make them return a VersionAndBranch 1.0.2 and a VersionPoint 1.0?

Looks good to me, @SimonCropp?

Sent from my iPhone

On 20 nov 2013, at 16:05, nulltoken [email protected] wrote:

Those commits come from #32. I've opened a separate PR as they should be ready to be reviewed

Most notable change lies in NewestSemVerTag(). Indeed, LibGit2Sharp doesn't enforce Tags (nor any References) to be returned in a sorted order.

As such, the call to Reverse() has been removed and the selection of the highest version to be returned has been delegated to SemanticVersion.

In order to ease the review of the commit diff, indentation fixes have been pushed in a separate commit.

You can merge this Pull Request by running

git pull https://github.com/nulltoken/GitFlowVersion ntk/fix/miscellanea
Or view, comment on, or merge it at:

#36

Commit Summary

Improve ShortVersionParser.TryParseMajorMinor() test coverage
Refactor ShortVersionParser.TryParseMajorMinor()
Enforce NewestSemVerTag() test coverage
Fix indentations
Make NewestSemVerTag() cope with unordered tags
File Changes

M GitFlowVersion/LibGitExtensions.cs (32)
M GitFlowVersion/ShortVersionParser.cs (22)
A Tests/LibGitExtensionsTests.cs (54)
M Tests/ShortVersionParserTests.cs (20)
M Tests/Tests.csproj (1)
Patch Links:

https://github.com/Particular/GitFlowVersion/pull/36.patch
https://github.com/Particular/GitFlowVersion/pull/36.diff

@nulltoken

As such, the call to Reverse() has been removed and the selection of the highest version to be returned has been delegated to SemanticVersion.

I think this is actually incorrect. Or more specifically less correct. The intent of the previous code was to retrieve the newest tag, not the tag with the highest version. So if someone pushes a new tag we use that over the other ones despite the version. Admittedly it is unlikely that someone would push a smaller version tag to the same commit so most of the time the highest version would be correct.

However i added this extension method to find the newest tag https://github.com/Particular/GitFlowVersion/blob/master/GitFlowVersion/LibGitExtensions.cs#L38

does this look ok to you?

@SimonCropp Thanks for the merge! BTW, next time I'm not in line with your expectations, please let me just know and I'll update the PR accordingly. It'll avoid you wasting time over my mistakes/misunderstandings 😉

does this look ok to you?

Looks fine to me. I think there might be a tiny corner case. I'll send a PR about it if I can come up with a failing test.

next time I'm not in line with your expectations, please let me just know and I'll update the PR accordingly. It'll avoid you wasting time over my mistakes/misunderstandings

I would have but i pushed the shinny green merge button before i realized. and i was my poor code that caused the confusion.