[Question] remove issue tracker keywords from commit message

[Martin Kausche]

Hi.

It is possible to interact with certain issue trackers by including keywords in your commit messages, see here for how it is done with the github issue tracker.

An example commit message could be:

fix: Removed all errors (fixes #11, #12, #13)

I dont want these keywords/commands in my changelog since most endusers dont know what these mean or dont have access to the issue tracker.
Is there a designated way to remove these keywords/command from the generated changelog?

---

For now I extended subject_process in my .gitchangelogrc to this (added the third line):

subject_process = (strip |
    ReSub(r'^([cC]hg|[fF]ix|[nN]ew)\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n@]*)(@[a-z]+\s+)*$', r'\4') |
    ReSub(r'\s\(\s*.+#\d+\s*\)\s*', r' ') |
    SetIfEmpty("No commit message.") | ucfirst | final_dot)

but if there is a build in solution I would prefer this.

[Martin Kausche]

update 2017-12-07: made it a bit more robust, see here

subject_process = (strip |
    ReSub(r'^([cC]hg|[fF]ix|[nN]ew)\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n@]*)(@[a-z]+\s+)*$', r'\4') |
    ReSub(r'\s\(\s*[A-z]+\s*#\d+\s*\)\s*', r'') |
    SetIfEmpty("No commit message.") |
    ucfirst |
    final_dot)

[Valentin Lab]

Sorry for the very late answer. You've got the right way to do it.
I'm curious, what where you thinking when mentioning "built-in" solution ?

There are a lot of different use cases for managing commit messages, and gitchangelog decides to give the full power to the user thanks to the .gitchangelog.rc and those option that you actually managed to use yourself. All the default behaviors of gitchangelog are actually defined in the configuration file, and we try to remove as much features as built-in.

If you are unsure about your regex, we can probably help you fine tune it. It does not seem optimal at all at first glance. If you are sure for instance that you'll use the 3 letter "fix" and that the parenthesis will appear at the end of the subject, you can avoid many issues.

    ReSub(r'\s*\(\s*[Ff][Ii][Xx][^)]+\)\s*', r'') |

Thanks for your feedback.

[Martin Kausche]

Hi,

my goal is to be able to use certain keywords to interact with issue-trackers such as github (or other services that support such things).
At the same time I want to use gitchangelog to generate changelogs that do not contain any of these commands.

My self-imposed rule is to enclose these commands by brackets ( ).

The keywords are predefined by the issue tracker, see here for keywords/commands supported by github as an example.
Additionally I regularly use something like (see #123) to make a reference to an issue.

I supposed there wasn't a build-in solution (such as a command-line option) for this use-case, but I didn't want to miss the chance to ask for it :-).

[Valentin Lab]

Hi, I wanted to come back to you (very late) on this topic.

• so as for a removal of commands, it needs to be more specified... because I can't remove any reference that Github will detect. For instance, your summary could be: "This closes #34, closes #23", which matches github spec, and have a simple regex removal rule, will leave nothing in the summary. This implies that you have to use a personal rule above github rules, a little like the usage of new|chg|fix that we use to classify commits in the default proposed rules. Using parenthesis, as you suggest, is a good proposition for a personal rule as it can very easily be removed (as demonstrated in my previous message).

• I wanted to bring to your attention that you can also use trailer-key values that github will see (and are probably the most elegant solutions). To clarify, this means using in the end of your commit descriptions, some lines like: Closes: #XX. These are naturally removed by gitchangelog (and accessible if you want to through dedicated access in the data structure provided to templates.)

• For built-in solutions, well, this could be brought through clever implementation of a GitHubCommandsRemove(..) filter, that you can provide as a PR if you feel so (with documentation). I'll gladly provide this as an optional filter if the underlying policies you've chosen seem sound enough.

I'll close this issue for now, as I feel the topic was addressed. I you feel like something should makes it way to the code, I'll be happy to open it, especially if you can elaborate a clear enough specification. Many thanks for your feedback, I always appreciate it, even if I may take (a very long) time to answer them some times. Sorry about that. And thanks for your patience.