Support for Team Foundation Server merge messages

[joergmetzler]

I added support for the default merge messages for pull request in Team Foundation Server 2017.
The bad news:
If there is only one commit in the pull request, the TFS will copy the commit message into the merge message and will not use the default commit message.
Any ideas for this problem?

[asbjornu]

@JakeGinnivan, @gep13: Why are we detecting merge messages to deduce whether a commit is a merge or not? Shouldn't this be a simple parents.Count > 1 check?

[joergmetzler]

If the master branch only accept pull requests and an automatic build starts on every commit, then then the version is incremented wrong because of a missing tag. The version tag is added later e.g. due to git version release finish. The release branch may be deleted when the pull request is accepted.
So the version is extracted from the merge message as a workaround.
Think it is not a good behavior.

In the meantime we changed the build trigger on the master to /ref/tags/* so that the build is triggered as soon as the tag is pushed and not before.
Works perfectly for all of our repos and we don't need to rely on the merge messages.

But if someone needs/wants to use the merg messages, you are free to accept the pull request.

[JakeGinnivan]

@asbjornu we extract the version from the merge message I think

[asbjornu]

@JakeGinnivan: Ah, I see. But I think that's an orthogonal issue. Figuring out whether it's a merge-commit or not should be an independent parents.Count check, imho.

@joergmetzler: I think the fix you've added is fine, but if you have ideas on how to improve this behaviour by (among other things) checking for the number of parents (or perhaps LibGit2Sharp exposes merge information out of the box) to detect whether a commit is a merge-commit or not, we would love a pull request for it.