From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS54825 145.40.73.0/24 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id BE0571F452 for ; Tue, 28 Nov 2023 15:30:29 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=gBugiC+V; dkim-atps=neutral Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id A1F6FCE1B23; Tue, 28 Nov 2023 15:30:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A9C3C433C7; Tue, 28 Nov 2023 15:30:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1701185426; bh=3Cmyr5EczmNPcryfGL7HIrt4trEarUERTymLJSCLQhY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gBugiC+VRdBQr5YB+/EWaYT623182cyFtA/CokPcGJ/OEFZ/ITrRudEAWWrLqjKxC e6LFSzILViAYqvZjSzZz1cS0TaOVXR4G8milO5FuIMqWddsCNFjaEP022+c4UguIoJ Rn3/kWM8knRL9hlbo9d0aV+hy6iNu2pascsFrWcg= Date: Tue, 28 Nov 2023 10:30:25 -0500 From: Konstantin Ryabitsev To: Eric Wong Cc: meta@public-inbox.org, workflows@vger.kernel.org Subject: Re: extra search flags and params? (ispatch, replycount, ...) Message-ID: <20231128-classy-brown-muskrat-7f07b1@nitro> References: <20231128001028.M189230@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20231128001028.M189230@dcvr> List-Id: On Tue, Nov 28, 2023 at 12:10:28AM +0000, Eric Wong wrote: > Would they be useful? > > It's not currently possible to quickly search for whether or not > a term (e.g. patchid:) is present in a Xapian document. Having > the ability to do so would make it easier to find non-patch messages, > or easily filter down to cover letters, bot replies, etc... I understand the reasoning, but I'm not sure we should be trying too hard to make public-inbox a patch tracking platform. What makes lei great is ability to automatically find and retrieve entire threads -- I feel like we should leave series tracking to other platforms that already exist (patchwork, patchew, etc). > I don't think any of these would be required to get "lei rediff" > working on entire patchsets, though (it only does individual > messages, currently). Incidentally, I've recently discovered that relying on git-patch-id to match commits to message archives has some important flaws. Linus was actually the one who caused this when he recommended that maintainers switch to using the "histogram" diff algorithm instead of the default ("myers"). This made me realize that there's actually a multitude of ways the same patch can be represented (diff-algorithm, number of context lines, etc) that would cause git-patch-id to return a different value for the exact same commit. So, while I know that Linus doesn't want Link: entries in commits that just go to the series, using the message-id remains the only mechanism to reliably link commits to the series discussion. -K