Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Tue, May 10, 2022 at 5:24 AM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: >> >> A last minute fixup of the transitional ID numbers. >> Important to get these right - if users start to depend on the >> wrong ones they are very hard to fix. > > Hmm. I've pulled this, but those numbers aren't exactly "new". > > They've been that way since 5.14, so what makes you think people > haven't already started depending on them? > > And - once again - I want to complain about the "Link:" in that commit. > > It points to a completely useless patch submission. It doesn't point > to anything useful at all. > > I think it's a disease that likely comes from "b4", and people decided > that "hey, I can use the -l parameter to add that Link: field", and it > looks better that way. Some folks have been doing it since the early 2010s. But I think it really took off after the Change-Id discussion a few years back: https://lore.kernel.org/all/CAHk-=whFbgy4RXG11c_=S7O-248oWmwB_aZOcWzWMVh3w7=RCw@xxxxxxxxxxxxxx/ Which I read as you endorsing Link: tags :) > And then they add it all the time, whether it makes any sense or not. For me it always makes sense, because it means I can easily go from a commit back to the original submission. That's useful for automating various things like replies and patchwork status updates. It allows me to find the exact patch I applied, even if what I committed is slightly different (due to fuzz or editing), which would be harder with a search based approach. It gives us a way to essentially augment the change log after the fact, by replying to the original patch with things we didn't know at the time of commit - eg. this patch was reverted because it caused a bug, etc. If you follow the Link: and there's nothing useful there explaining what motivated the change then that's a bug in the patch submission, not the Link: tag. Really important information should be in the change log itself, but the space below the "---" is perfect for added context that would be too verbose for the committed change log. And anyone can reply to the original submission to add even more useful information. cheers
