User-specified template file instead of interactive dialog about git-cm

[matu3ba]

@sirwindfield ping.

[matu3ba]

Yes, you nailed it.
Conventional commits does not specify the body of keywords.

And I wanted to force the text for the user to be as short as possible for a MVP.
How do you want to proceed on this?

[mainrs]

Thanks for the ping, I did actually forget to answer :)

So after reading this a couple of times I think I got it. Your idea sounds more like something that is useful in cases where the template does change during the lifecycle of the application or is introduced into one that did not rely on a commit message convention. Especially by declaring the commit hash range, templates can be applied to different ranges of the (pre-existing) commits inside a repository.

The way I understood it is that you can define templates for various types of commits, let's just go with the two mandatory ones, feat and fix. In that case you'd have two templates, one that matches the feature and one the fix commits. Each has metadata that can be used to match it against the right commits (the hash range). The tool would then warn the user if a commit has a matching template but is not formatted accordingly.

Given the fix example you gave, I understood it that fix templates would be allowed to only have footers of type Fixes, Closes, PR-Close. Everything else would be interpreted as false and the tool could return an error/abort/whatever. The body has no restrictions set to it, but the description does. It is only allowed to be one line long. So this would fail to lint correctly:

fix(scope): this is a message
split into two lines

Is that correct? :)

[mainrs]

It sounds like a neat feature to be honest and I like it! I will probably implement something along the lines of this. I am currently cleaning up all the code that I want to publish to @conventional-commits-rs before I proceed on working on this program :)

I currently want to push and publish all the necessary crates to work inside the conventional commits ecosystem for Rust. After that, I will go back and improve this crate as well. In it's current state, it works with conventional commits and that was my main goal :)

That being said, I need to keep somewhere track on stuff that might be useful inside this tool. This is, however, a feature I am looking into implementing. I am not sure though if I will put it in here or into https://github.com/conventional-commits-rs/commitlint.