[Webkit-unassigned] [Bug 266028] Ending a commit message with `Co-authored-by` to credit multiple authors doesn’t work because `Canonical link` gets added by the merge queue
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Mar 1 06:55:51 PST 2024
https://bugs.webkit.org/show_bug.cgi?id=266028
Sam Sneddon [:gsnedders] <gsnedders at apple.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |emw at apple.com,
| |gsnedders at apple.com,
| |repstein at apple.com,
| |slewis at apple.com
--- Comment #3 from Sam Sneddon [:gsnedders] <gsnedders at apple.com> ---
(In reply to Alexey Proskuryakov from comment #1)
> AFAIK our tooling requires for canonical link to be the last line, so it
> wouldn't be easy to change.
It isn't quite a simple as "the last line", because e.g. git-svn-id appears after it (see 200001 at main). I think we might just treat git-svn-id as a special-case though?
At this point when everything is using git, we should just be using git-interpret-trailers, which would also solve the underlying problem.
*However*, git changed their behaviour to disallow whitespace in trailer names in 2016, https://github.com/git/git/commit/e4319562bc2834096fade432fd90c985b96476db, in git 2.12.0, though wasn't properly documented until 2022, https://github.com/git/git/commit/b46dd1726c139c930d7b4b7c3262e3f2699987d3, git v2.38.0, thus our "apparent" trailer of "Canonical Link" is no longer a valid trailer name.
Our path forward here is probably a multi-step one:
1. Allow *either* a final line of "Canonical Link: XXX" (or followed by a git-svn-id line?) _or_ a "Canonical-Link" trailer in the trailers block.
2. Migrate to outputting a Canonical-Link trailer once we believe (1) has landed long enough ago.
Long term, this would allow us to do things like `git log --pretty='format:%(trailers:key=Canonical-Link)'` once we rarely care about the history commits with a space.
That said, different vendors may have their own tooling hard-coding "Canonical Link" which would also need changed (e.g. Apple's perf infrastructure apparently does this), so this probably does need some broader communication *especially* before step 2.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240301/36291605/attachment.htm>
More information about the webkit-unassigned
mailing list