Allow action/audience/tag to be pulled from the commit body instead of subject

[exhuma]

I really prefer to keep my subject lines short and to the point. I do try to keep them below the recommended 50-char limit as much as possible. Which is already quite hard to do.

Adding action/audience/tag to the subject leaves almost no room for the actual message.

Looking through the config example, I came across subject_process and body_process. But neither seems to be able to do this. For example, I couldn't use body_process to make a change in the subject line.

Is there a way to pull these details from the body? If not, would it be possible to add this feature?

[vaab]

Yes, I don't follow the 50-char limit and am not really convinced enough about the arguments in favor of this. But, anyway, I'm in favor of supporting any workflow and will happily help you achieve your goals.

You are right, the section is computed from the subject only right now, thanks to the section_regexps, and there are no reason to limit that.

This is a feature I'd like to see implemented in gitchangelog as well. Many thanks for the feedback.

[exhuma]

You're welcome 😄

I am also a bit torn apart with the 50 char limit, but have run into a few cases where it has been really useful. Especially when doing "revert" commits:

git prefixes revert commits with the "Revert" text which adds to the overall length... come tho think of it: How would gitchangelog handle those? (but that's nothing to be put into this issue 😉)

I also have used tools which are quite greedy with horizontal screen-space (tig for example). Especially if you have many branches:

I think the 50-char limit definitely has its merits! And keeping the subject lines as short as possible is always on my mind for exactly those reasons.

[vaab]

Thanks for your compelling arguments, not totally unbeknown to me... and it is nice to see them rightfully illustrated with nice screen-shots. I'm not myself totally sure of my decision of not following the 50-chars. I happen to favor heavy editing of the git log history before pushing a branch, considering the actual pushed history part of the doc, and so I avoid many cases of "Reverted" or merge jungle (that I may use heavily while developing, but that I seldom push on the main branches.)

[vaab]

Thanks for your compelling arguments, not totally unbeknown to me... and it is nice to see them rightfully illustrated with nice screen-shots. I'm not myself totally sure of my decision of not following the 50-chars. I happen to favor heavy editing of the git log history before pushing a branch, considering the actual pushed history part of the doc, and so I avoid many cases of "Reverted" or merge jungle (that I may use heavily while developing, but that I seldom push on the main branches.)

[exhuma]

Same here. But the a "merge jungle" like the one above is sometimes difficult to avoid. Especially if working in a team and getting merge-requests and want to preserve a history combining the work of multiple contributors.

And for the case of the "reverted" commits: The only reason why they exist is because the original commits were already pushed to the public repo. I could have just rebased the branch and just not included the reverted commits, but that would have changed history and most certainly impacted work of other team members.

I agree that something like this is rare, but it does happen.

[mbarakaja]

Hello @vaab. What is the status of this issue?