Oh no, Linus is yelling at me. I think that's a first.

@monsieuricon What did you do?

@monsieuricon 🏆

I suspect that the information Linus is looking for is very different from what other people are looking for. I can tell you that I/we use the Link: URLs _all the time_ to get more context for a patch, usually to look at the discussion to see why something was done or not done in a specific way. If it's not there you put the patch subject in lore or google (but it's an extra step). These are common workflows...

@vegard @monsieuricon same here, even a link to the latest version that is just the patches + an applied message is usually helpful since the cover letter often contains links to the previous versions (especially if they've been prepared and sent using b4 as well)

@sven @vegard @monsieuricon yeah, cover letter is nice – but TBH I even like it better when they end up in a git merge commit (bpf subsystem and a few other do that).

What I like most: being able to reply to the patch posting, as you can simply "reply-to-all" to the last submission to reach everyone relevant and all mailing lists in case of a bug or something (use with care, sometimes you have to remove some people).

@kernellogger @vegard @monsieuricon I hadn't seen a cover letter turned into a merge commit before and that indeed sounds very helpful as well.

@sven @vegard @monsieuricon for completeness, in case some readers here wonder how that looks like:

https://git.kernel.org/torvalds/c/4d2815a1cc3dffde425acc448247d74ccdc94bc9

@kernellogger @sven @vegard @monsieuricon I do that religiously as well. Every multi-patch series gets a merge commit (forwardable or not).

@kernellogger @sven @vegard @monsieuricon But the links are useful independent of that. They simply provide a trivial jumping point to lore. If the series was managed via b4 it's trivial to back to all version of the same patchset.

The benefits for everyone else should simply be what counts here, not a perceived discomfort.

@kernellogger @sven @vegard @monsieuricon The other thing is: Either make it official policy that you don't want to see any Links in the commit messages or just accept that some people do and some people don't. But if you make it a policy then document it somewhere, please.

@kernellogger @sven @vegard @monsieuricon and how a simple request did spiral into a philosophical discussion of this dimension is a bit beyond me as well. We could've just ended this with "I personally don't like the links. If others find them useful then great but please don't try to convince others to add them." End of story, everyone is happy and can move on.

@brauner @sven @vegard @monsieuricon

guess this whole episode shows some of the downsides of how we work:

* Those that find links to patch posting (or something like it) really helpful (/me included!) apparently fail to reach Linus here.
* A lot of workflow things are not documented – and the Documentation at the same time is ignored by many (which is understandable, as it's a lot and sometimes hard to grasp)
* Linus sometimes has to explain things multiple times (he stated his dislike for links to patch posting a few times in the past), which might contribute to why this quickly led to a "philosophical discussion of this dimension"

@brauner @sven @vegard @monsieuricon many thx for that, it's really great!

@ljs @brauner @sven @vegard @monsieuricon

fwiw: The mm approach is better than dropping the cover letters, but I dislike it. Among others because it mixes "this is what the patch is about" with "this is what this series is about" – and it also is harder to see where a series ends.

@monsieuricon he's a BDFH not BDFL

@vbabka @monsieuricon Hate/Love?

@epilys @monsieuricon it's a combo of BDFL and BOFH

@brauner @kernellogger @sven @vegard @monsieuricon IIRC Linus also doesn't like unnecessary merge commits? So doing a merge commit for the purposes of cover letter is sufficient excuse?

@vbabka @kernellogger @sven @vegard @monsieuricon back merges

@ljs @kernellogger @brauner @sven @vegard Well, not just that, but he makes assumptions that are incorrect (like that we can always match a patch with the commit using git-patch-id). I realize provenance links are not useful to *him*, but they play an important role for a lot of other people and tools in the Linux ecosystem.

@kernellogger @sven @vegard `b4 shazam -M` will create these merge commits automatically and let you edit the cover letter to trim it down if needed.

@monsieuricon @kernellogger @ljs @vegard @sven absolutely

@monsieuricon @kernellogger @ljs @vegard @sven my main worry now is whether we'll get pushback and aren't allowed to use Link: tags anymore. I don't want to change what we're doing now because it's so great.

And frankly, I don't see why my own series where submitter == maintainer needs to be special. It literally helps everyone else if they have a Link: tag as well.

@brauner @monsieuricon @ljs @vegard @sven

"aren't allowed to use Link: tags anymore" might happen, but I doubt it: we had similar discussion (and thus fears) before, but in the end it seemed that Linus didn't care enough to put a stop to them

@sven @kernellogger @vegard @monsieuricon I do that as well - b4 will save the cover letter for you as part of b4 am which makes it relatively straightforward to script, I do a light edit by hand rather than try to fully automate since there’s often a bunch of admin/process stuff in the mail.

@broonie @sven @kernellogger @monsieuricon And I'm guessing you can also use the git log/diff rev^- shorthand syntax to see (only) the patches/changes in the series where "rev" is the merge commit. (e.g. `git diff HEAD^-` just after b4 am)