I'm quite disappointed in Gitlab for this. I briefly popped in to
#gitlab to make sure that there was no recourse for this. Sadly, it
seems that there is not.

On Tue Nov 28, 2023 at 4:46 PM PST, Bryan Davis wrote:
> [...]
> In my estimation, the problem comes down to a question of whether we
> should prioritize reading commit message footer information nicely in
> GitLab's merge request interface where they are rendered as GitLab
> flavored markdown data or not. James' team has developed a convention
> of appending a backslash (\) after footer lines so that they render as
> individual lines when processed as markdown. This in turn leads to
> commit-message-validator rejecting some footers, most obviously "Bug:
> Tnnnn" footers, for having unwanted characters (the trailing " \").
> Reasonable people can disagree on the "best" solution here, but I
> think it is likely that as a group we can reach consensus on what the
> proper behavior of the commit-message-validator tool should be. The
> most obvious options are:
> * Change nothing in commit-message-validator and suggest folks live
> with markdown rendering artifacts in GitLab merge request
> descriptions.
> * Change commit-message-validator to allow trailing " \" data for
> commit message footers in GitLab repos.
> * Change commit-message-validator to allow users (typically a CI
> process) to configure allow/disallow of trailing " \" data for commit
> message footers

IMO Markdown does not belong in a commit message. Markdown in commit
messages is analogous to HTML in email.

A middleground could be to prefix the Bug: lines with hyphens so Gitlab
would interpret them as a list. :/

Attachment: signature.asc
Description: PGP signature

Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org

Reply via email to