On Mon, 12 May 2025 at 23:03, Alejandro Colomar <a...@kernel.org> wrote: > > Hi Jonathan, > > On Mon, May 12, 2025 at 05:42:55PM +0100, Jonathan Wakely wrote: > > On Mon, 12 May 2025 at 17:34, Jonathan Wakely <jwak...@redhat.com> wrote: > > > > > > On Mon, 12 May 2025 at 16:46, Alejandro Colomar <a...@kernel.org> wrote: > > > > > > > > contrib/ChangeLog: > > > > > > > > * gcc-changelog/git_commit.py (GitCommit): > > > > Add support for 'Link:' tags. > > > > > > > > Cc: Jason Merrill <ja...@redhat.com> > > > > > > I don't think we want a Cc: trailer in the actual commit message. do we? > > Ahh, yep, we can remove it. (I'd keep it, but since the script doesn't > support Cc: either, and Joseph seems against that tag, I won't try > convincing you.) > > > > > > > What is a Link: tag? I assume this is some kind of Git trailer, but > > > what for? A URL? > > Yes. > > > > Why do we need to use a Git trailer for that instead > > > of just putting the URL in the commit message body? > > I'm used to link tags. They keep the links relatively organized at one > per line. I could add some accompanying text for each link, but that'd > be filling text for links that are better explained by themselves when > you open them. I think the links by themselves make for a cleaner > commit message. (Of course, there are exceptions, and some commits need > an explanation for links, but in this case there's no need, IMHO.)
Makes sense. > > It seems to be one of the more common trailers used in the linux > > kernel [1], > > Yep. I also use them in the man-pages project. > > > but this isn't the kernel. > > Yep. > > > Why do you "need" it for GCC? > > Need is too strong. I think my commit message would be nicer with them. > I could add a paragraph for each link (or maybe several together in > one). But even then, the link breaks the line at some weird point, and > it reads better with a link per line. I don't know; it looks cleaner to > me. Makes sense. > > We shouldn't be copying conventions from other projects just because > > that's how somebody else does things. > > If you've followed what I do in the man-pages project, you may know that > I don't usually follow conventions blindly just because someone else > did. If I do, it's because I find it useful to me. On the other hand, > you may find it not useful, in which case, it's up to you in this > project. > > > What benefit is there to GCC to > > doing this, and requiring changes to our tools to support it? > > Cleanliness. Fair enough, I have no objection to adding Link: support to the git_commit.py script. (We don't really have anybody who is the owner of those scripts now, so I think you need a global reviewer to approve it.) > > [1] > > https://www.reddit.com/r/git/comments/nl36wl/the_top_1_commit_trailers_of_gitgit/ > > > Have a lovely night! > Alex > > -- > <https://www.alejandro-colomar.es/>
