From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 952A51F5AE for ; Thu, 29 Apr 2021 20:14:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236854AbhD2UP1 (ORCPT ); Thu, 29 Apr 2021 16:15:27 -0400 Received: from cloud.peff.net ([104.130.231.41]:40320 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236795AbhD2UPX (ORCPT ); Thu, 29 Apr 2021 16:15:23 -0400 Received: (qmail 16230 invoked by uid 109); 29 Apr 2021 20:14:35 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Thu, 29 Apr 2021 20:14:35 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 22514 invoked by uid 111); 29 Apr 2021 20:14:35 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Thu, 29 Apr 2021 16:14:35 -0400 Authentication-Results: peff.net; auth=none Date: Thu, 29 Apr 2021 16:14:34 -0400 From: Jeff King To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: Junio C Hamano , Derrick Stolee , git@vger.kernel.org, Taylor Blau , Patrick Steinhardt Subject: Re: Nesting topics within other threads Message-ID: References: <87k0omzv3h.fsf@evledraar.gmail.com> <1ecb3727-106f-3d04-976a-36aa03a61caf@gmail.com> <8735v9z32l.fsf@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8735v9z32l.fsf@evledraar.gmail.com> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Apr 29, 2021 at 02:14:52PM +0200, Ævar Arnfjörð Bjarmason wrote: > > I really appreciate the way some people (Peff is a stellar example, > > but there are others who are as good at this) handle these tangents, > > where the message sent to an existing thread is limited to only give > > an outline of the idea (possibly with "something like this?" patch > > for illustration) and then they quickly get out of the way of the > > discussion by starting a separate thread, while back-referencing "So > > here is a proper patch based on the idea I interjected in the > > discussion of that other topic." And the discussion on the tangent > > will be done on its own thread. > > In RFC 822 terms. Are you talking about the In-Reply-To[1] or > References[2] headers, or both/neither? Since I got listed as an example, I can tell you what I do: I start a totally new thread with no in-reply-to or references to the old thread. And the subject is new (usually "[PATCH 0/N] foo..."), so no clever group-by-subject heuristics will link them. It's usually a good idea to reference the message-id/lore link in at least one direction, though (usually I'd do it in the new thread, saying "this is a followup to ...", but you could also follow-up in the original to say "I've spun this off into its own series here..."). Which is really _sort of_ like putting it into "References", except that it's not machine readable. Which is a good thing, because it's a weaker form and doesn't tell mail clients to group it all into one thread. > Threading isn't a concept that exists in E-Mail protocols per-se. Just > In-Reply-To and References. The References header can reference N > messages most would think about as a separate "thread", and "thread" is > ultimately some fuzzy MUA-specific concept on top of these (and others). > > E.g. in my client right now I'm looking at just 4 messages in this > "thread", it doesn't descend down the whole In-Reply-To, others would > act differently. Interesting. Mutt (and notmuch, and public-inbox) definitely view these as part of a larger thread. It looks like you're using mu4e; I'm surprised it doesn't, too (of course some clients will give a partial view of a thread if you've already marked the older messages as read and moved them into an archival folder). > It seems to me to be better to veer on the side of using standard fields > for their intended purpose for archiving / future use. I.e. making "a > reference" universally machine-readable, as opposed to a lore.kernel.org > link, or a free-form "in a recent thread" blurb. I'd disagree here. There's a long history of intentionally breaking the thread in mailing lists and newsgroups exactly because the topic is sufficiently different that you want to make it easy for people to treat it as a separate unit. I admit there's a bit of an art form to deciding when that is appropriate and when not. -Peff