Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Oct 13, 2025 at 10:00:01AM -0700, Linus Torvalds wrote:
> What's the real argument against "b4 dig"?

At the moment:

   https://goomics.net/50

"There are two ways of doing things at Google; the deprecated way
(e.g., Link Tag), and the one which isn't ready yet."   :-)

It's *close*, and it's not yet available to most developers unless
they are running out of b4's git HEAD.  I did try using it on a
selection of patches, and I was pleasantly surprised how often it
worked.  But it's definitely not perfect.  For example:

% /usr/projects/linux/b4/b4.sh dig -c 1d3ad183943b38eec2acf72a0ae98e635dc8456b
Digging into commit 1d3ad183943b38eec2acf72a0ae98e635dc8456b
Attempting to match by exact patch-id...
Trying to find matching series by patch-id 7f91856ff1f9b87a4fcaf69134fc715a706cb86a
Grabbing search results from lore.kernel.org
WARNING: duplicate messages found at index 1
   Subject 1: Forwarded: [PATCH v3] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
   Subject 2: Forwarded: [PATCH v4] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
  2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
   Subject 1: Forwarded: [PATCH v2] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
   Subject 2: Forwarded: [PATCH v3] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
  2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
   Subject 1: Forwarded: [PATCH] ext4: validate extent entries before caching in ext4_find_extent()
   Subject 2: Forwarded: [PATCH v2] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
  2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
   Subject 1: Forwarded: [PATCH] ext4: validate extent entries before caching in ext4_find_extent()
   Subject 2: Forwarded: [PATCH] ext4: validate extent entries before caching in ext4_find_extent()
  2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
   Subject 1: Forwarded: [PATCH] ext4: fix BUG_ON in ext4_es_cache_extent due to out-of-order extents
   Subject 2: Forwarded: [PATCH] ext4: validate extent entries before caching in ext4_find_extent()
  2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
   Subject 1: Forwarded: [PATCH] ext4: fix BUG_ON in ext4_es_cache_extent due to out-of-order extents
   Subject 2: Forwarded: [PATCH] ext4: fix BUG_ON in ext4_es_cache_extent due to out-of-order extents
  2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
   Subject 1: Forwarded: [PATCH] ext4: Fix extent boundary validation in extent tree
   Subject 2: Forwarded: [PATCH] ext4: fix BUG_ON in ext4_es_cache_extent due to out-of-order extents
  2 is not a reply... assume additional patch
Found matching series by patch-id
---
This patch is present in the following series:
---
  v1: Forwarded: [PATCH] ext4: Fix extent boundary validation in extent tree
      https://lore.kernel.org/r/68d8e78f.050a0220.25d7ab.04c8.GAE@google.com
  v4: [PATCH v4] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
      https://lore.kernel.org/r/20250930112810.315095-1-kartikey406@gmail.com

If you look at the first Lore URL, it is absolutely NOT CORRECT.  This
isn't purely b4's fault.  the problem is we have some developers who
are blindly sending random patches bashing at the code to see if they
can make syzbot stop complaining.  But it results in a fairly
confusing patch history.


I can also imagine some UI polish; for excample, a bunch of *how* b4
dig tried to find thigns should probably only show up with a -v
verbose option.

And when displaying thje results, it would be useful if it (a) printed
the date (and how it relates to the commit date), and (b) flag whether
the patch-id is an exact match, or whether it isn't with perhaps some
kind of diference score, so the human being knows whether they need to
take a closer look.

					- Ted

P.S.  "Mindless" is also a way of saying, "decreasing the load on
overloaded maintainers".  Something like a mindless inclusion of a
Message-ID tag would add an extra 60-80 characters of overhead into
the commit trailer; I can understand why Linus might not like it, but
from the perspectve of saving time from maintainers, I'm going to be
selfish enough to want something that saves me time.

If "b4 dig" can be made good enough that 99% of the time, it works
just as well as mnually inserted metadata, great!  It's just that "b4
dig" is still a little rough around the edges, and I suspect many
people haven't tried using it yet.  Hence the interest in other
alternatives...