Enable custom merge message formats via configuration

[Kieranties]

NOTE: This PR has is dependent on the breaking changes introduced by #1487 and should not be approved unless the related breaking changes are approved.

This PR enables custom merge message formats to be added via configuration.

I've now used GitVersion on a few build systems but only ran into issues with merge messages when migrating to TFS. TFS merge messages vary depending on if the merge is a PR, has one or more commits, or is customised by the user completing the PR. In many cases, the merge message will be Merged PR 1234: . this sadly does not fit the baked-in messages that come with GitVersion.

Instead of simply adding another entry into the defaults, this PR enables user to add custom messages formats into their configuration.

[Kieranties]

@asbjornu All synched up and green 🎉

[asbjornu]

This looks good, although I have a tingling sense this steps on other pull requests we've recently merged or that are still open. I can't find them now, though, so I might be wrong. I also have a couple of questions I'd appreciate some feedback on.

[Kieranties]

@asbjornu I've some time tomorrow to tidy things up as required, then will be AFK for a few days. Let me know what you want to do on the last two points above

[Kieranties]

@asbjornu Did you have any further response on the code review? I'll be able to address things this evening. It seems the appveyor build failed for an unrelated reason.

[asbjornu]

I think this mostly looks good. But I'm thinking, could perhaps merge-message-formats replace the entire TFS merge message support that was implemented in #1591?

[Kieranties]

I think this mostly looks good. But I'm thinking, could perhaps merge-message-formats replace the entire TFS merge message support that was implemented in #1591?

Absolutely, but you'll have a regression for consumers of that change. They will need to update their configuration to cater for the TFS messages when they update to 5.0

[asbjornu]

Absolutely, but you'll have a regression for consumers of that change. They will need to update their configuration to cater for the TFS messages when they update to 5.0

Couldn't the TFS merge messages be added as defaults in merge-message-formats?

[Kieranties]

Couldn't the TFS merge messages be added as defaults in merge-message-formats?

I might be confused... Do you mean adding to the default configuration class itself? I'm not sure I see the benefit.

[asbjornu]

I might be confused... Do you mean adding to the default configuration class itself? I'm not sure I see the benefit.

Don't worry. If anything, I'm the confused one. 😄 I'm thinking that the merge-message-formats implementation can add the TFS merge messages as defaults so the TFS merge message support isn't lost, it's just migrated over to the merge-message-formats property.

[Kieranties]

@asbjornu Anything else to do here?

[asbjornu]

@Kieranties, I don't feel we've got the same understanding of the relationship between merge-message-formats and the TFS merge messages. I still have a feeling we could implement the support for TFS merge messages with the merge-message-formats feature, I'm just unsure how.

Think of it this way: If this PR was merged before #1591, could #1591 have looked differently? If so, how? If we're able to describe "how", I would love to have that implemented in this PR.

[Kieranties]

@asbjornu if this had been completed before #1591 then the user would be able to add the following to their configuration:

merge-message-formats:
  TfsMergeMessageEnglishUS: ^Merge (?<SourceBranch>[^\s]*) to (?<TargetBranch>[^\s]*)
  TfsMergeMessageGermanDE: ^Zusammengeführter PR ""(?<PullRequestNumber>\d+)""\: (?<SourceBranch>.*) mit (?<TargetBranch>.*) mergen")

... and #1591 would never have been needed.

However, as #1591 has already been implemented, the above already exist as defaults in the MergeMessage class. So now there is no need for any user to ever specify them, unless they are removed from the list of defaults.

merge-message-formats allows users to specify any number of custom merge messages that will always be evaluated before the built in defaults. So they can add additional formats for existing git systems, or formats for new systems without having to wait for GitVersion to implement a default.

[asbjornu]

Ok, thanks for the explanation, @Kieranties. It all makes sense now. Then we only have to decide whether we want to undo the changes introduced in #1591 just to keep the core of GitVersion as simple as possible. How do you feel about that, @joergmetzler?

[joergmetzler]

I'm fine with that.

[asbjornu]

@joergmetzler: Awesome. Can you please effectively revert #1591 then, @Kieranties? I'll be quick to approve and merge after.

[Kieranties]

I'll pick this up this evening. You'll need to highlight the regression though right?

…

On Fri, 10 May 2019 at 14:25, Asbjørn Ulsberg ***@***.***> wrote: Awesome. Can you please effectively revert #1591 <#1591> then, @Kieranties <https://github.com/Kieranties>? I'll be quick to approve and merge after. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1488 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACVZPZBTZIIR5O4CMGC3E3PUVZVPANCNFSM4FYRALJQ> .

[Kieranties]

Ah! Just spotted it's a new thing in 5.0 as well. No regression then 👍

[Kieranties]

@asbjornu Good to go!

[asbjornu]

Awesome, thank you so much for the great work and patience, @Kieranties!