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. :/
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 https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
