search

clog-tool / clog-cli

Generate beautiful changelogs from your Git commit history
MIT License
858 stars 43 forks source link

Adds support for #31 #32

Closed kbknapp closed 9 years ago

kbknapp commented 9 years ago

See the commit message of d91c479 for details

cburgdorf commented 9 years ago

Does this already allow us to create aliases to the "standard" sections Feature and Bugfix? E.g. can I configure it to make ft an alias for feat?

kbknapp commented 9 years ago

@cburgdorf Right now there are four hard-coded sections, Features and Bug Fixes, with aliases ft/feat and fix/fx respectively, and Unknown and Breaks. So the users can't take those away, but they can add their own sections.

For example, look at the latest clap changelog for the Improvements section (aliases to im).

One test I didn't run, but now that you mention it I'm curious how it would unfold, is to add a Features section and a different alias to see if it appends to the hard-coded Features section.

kbknapp commented 9 years ago

I just ran that test - If you add a Features section you in effect replace the hard coded aliases of feat and ft with whatever you choose. I'm going to submit a quick fixup to this PR which doesn't allow full overwriting of those aliases, just adding to. I.e. they could do:

[sections]
Features = ["abc"]

Which would then pick up all features with aliases feat, ft, and abc

kbknapp commented 9 years ago

6d0a17d allows users to add aliases to pre-defined sections, but not take them away.

Also, one thing I forgot to mention, you use sections with spaces:

[sections]
"My Great Section" = ["mgs"]

Which will work just fine...perhaps this should go in the readme?

cburgdorf commented 9 years ago

I'm going to submit a quick fixup to this PR which doesn't allow full overwriting of those aliases

I'm not sure if we really need to be that restrictive. Overwriting the predefined sections entirely sounds like a valid thing to me.

I think we can be quite liberal about that. As long as we keep clog flexible enough so that it can be configured to just work like the conventional changelog we should be fine I think. And with the current design it doesn't even need a configuration to work like the conventional changelog. It plays by those rules out of the box. I think it's ok to be able to completely overwrite those rules though.

kbknapp commented 9 years ago

Ok sounds good! I removed that last commit, this way it starts out fully compatible with the conventional changelog, but users can customize it from there.

cburgdorf commented 9 years ago

Awesome! Thanks :+1: