b4: ty: User-flow regression

b4: ty: User-flow regression

[Lee Jones]

For better or worse, I'm presently using the latest version of 0.15-dev,
specifically commit b87af2e0dc62 ("mbox: improve logging output for
shazam base selection") on the 'master' branch, which I recently rebased
to

After having done so, it seems as though my usual flow, which I've been
working with for a number of years, has stopped working reliably.  My
chosen flow goes like this:

-> Pipe mail from Mutt to a helper Bash script (apply-patch.sh)
-> Pull Message-Id out from mail
-> Use `b4 am` to save patch(es) to an *.mbox file
   -> b4.sh am -3 -st ${PATCHES} -o - ${id} > /tmp/<SANITISED_MSG_ID>.mbox
      * PATCHES is either "-P _" for single patches or "-P <RANGE>"
-> Run checkpatch.pl on the *.mbox file
   -> cat ${MBOX} | formail -ds ./scripts/checkpatch.pl || true
-> Apply the patch(es)
  -> cat ${MBOX} | git am -3 --reject
-> Amend / clean-up the commit messages as required
  -> kitty -o font_size=12 git rebase -i HEAD~${NOPATCHES}
-> Send out thank-yous
   -> b4.sh ty -aS --me-too --since=1.day

The that I'm highlighting occurs when changes have to be made to the
commit message.  My assumption is that the hash no longer matches and we
get:

 Auto-thankanating commits in for-mfd-next
 Found 5 of your commits since 1.day
 Calculating patch hashes, may take a moment...
 Nothing to do

Doh!  There should be something to do.

Did something change fairly recently to render this part of the
thank-you process less resilient to on-the-fly adaptions?  I don't
recall this happening before the update.

As ever, any help would be gratefully received.

-- 
Lee Jones [李琼斯]

Re: b4: ty: User-flow regression

[Konstantin Ryabitsev]

On Thu, Oct 09, 2025 at 04:13:49PM +0100, Lee Jones wrote:
> The that I'm highlighting occurs when changes have to be made to the
> commit message.  My assumption is that the hash no longer matches and we
> get:
> 
>  Auto-thankanating commits in for-mfd-next
>  Found 5 of your commits since 1.day
>  Calculating patch hashes, may take a moment...
>  Nothing to do
> 
> Doh!  There should be something to do.

Curious, have you set your diff.algorithm anywhere in your git config to
something like "patience" or "histogram"?

-K

Re: b4: ty: User-flow regression

[Lee Jones]

On Thu, 09 Oct 2025, Konstantin Ryabitsev wrote:

> On Thu, Oct 09, 2025 at 04:13:49PM +0100, Lee Jones wrote:
> > The that I'm highlighting occurs when changes have to be made to the

issue  ^

> > commit message.  My assumption is that the hash no longer matches and we
> > get:
> > 
> >  Auto-thankanating commits in for-mfd-next
> >  Found 5 of your commits since 1.day
> >  Calculating patch hashes, may take a moment...
> >  Nothing to do
> > 
> > Doh!  There should be something to do.
> 
> Curious, have you set your diff.algorithm anywhere in your git config to
> something like "patience" or "histogram"?

Not that I'm aware of:

  $ git config --get diff.algorithm
  <no output>

  $ git config --list | grep diff
  diff.wserrorhighlight=all
  diff.colormoved=zebra
  merge.conflictstyle=diff3

-- 
Lee Jones [李琼斯]

Re: b4: ty: User-flow regression

[Konstantin Ryabitsev]

On Fri, Oct 10, 2025 at 09:03:24AM +0100, Lee Jones wrote:
> > >  Auto-thankanating commits in for-mfd-next
> > >  Found 5 of your commits since 1.day
> > >  Calculating patch hashes, may take a moment...
> > >  Nothing to do
> > > 
> > > Doh!  There should be something to do.
> > 
> > Curious, have you set your diff.algorithm anywhere in your git config to
> > something like "patience" or "histogram"?
> 
> Not that I'm aware of:
> 
>   $ git config --get diff.algorithm
>   <no output>
> 
>   $ git config --list | grep diff
>   diff.wserrorhighlight=all
>   diff.colormoved=zebra
>   merge.conflictstyle=diff3

Next question is -- have you recently stopped adding Link: tags to your
commits? :)

-K

Re: b4: ty: User-flow regression

[Lee Jones]

On Fri, 10 Oct 2025, Konstantin Ryabitsev wrote:

> On Fri, Oct 10, 2025 at 09:03:24AM +0100, Lee Jones wrote:
> > > >  Auto-thankanating commits in for-mfd-next
> > > >  Found 5 of your commits since 1.day
> > > >  Calculating patch hashes, may take a moment...
> > > >  Nothing to do
> > > > 
> > > > Doh!  There should be something to do.
> > > 
> > > Curious, have you set your diff.algorithm anywhere in your git config to
> > > something like "patience" or "histogram"?
> > 
> > Not that I'm aware of:
> > 
> >   $ git config --get diff.algorithm
> >   <no output>
> > 
> >   $ git config --list | grep diff
> >   diff.wserrorhighlight=all
> >   diff.colormoved=zebra
> >   merge.conflictstyle=diff3
> 
> Next question is -- have you recently stopped adding Link: tags to your
> commits? :)

Oooo, yes!  Yes, I have!

Why would that make a difference?

-- 
Lee Jones [李琼斯]

Re: b4: ty: User-flow regression

[Konstantin Ryabitsev]

On Fri, Oct 10, 2025 at 03:34:52PM +0100, Lee Jones wrote:
> > Next question is -- have you recently stopped adding Link: tags to your
> > commits? :)
> 
> Oooo, yes!  Yes, I have!
> 
> Why would that make a difference?

When patches have been altered by the maintainer, we can no longer match them
by git-patch-id. In the past, when we found a Link: trailer, we could still
match their provenance by message-id, but if that is gone, we can no longer
fall back to that. I am working on making the "ty" mechanism being less
dependent on that -- hopefully the master branch should become more useful to
you again in the near future.

-K

Re: b4: ty: User-flow regression

[Lee Jones]

On Fri, 10 Oct 2025, Konstantin Ryabitsev wrote:

> On Fri, Oct 10, 2025 at 03:34:52PM +0100, Lee Jones wrote:
> > > Next question is -- have you recently stopped adding Link: tags to your
> > > commits? :)
> > 
> > Oooo, yes!  Yes, I have!
> > 
> > Why would that make a difference?
> 
> When patches have been altered by the maintainer, we can no longer match them
> by git-patch-id. In the past, when we found a Link: trailer, we could still
> match their provenance by message-id, but if that is gone, we can no longer
> fall back to that. I am working on making the "ty" mechanism being less
> dependent on that -- hopefully the master branch should become more useful to
> you again in the near future.

Thank you for the quick response and explanation, Konstantin.

I shall rebase with vigour!

-- 
Lee Jones [李琼斯]

Re: b4: ty: User-flow regression

[Greg KH]

On Fri, Oct 10, 2025 at 10:37:22AM -0400, Konstantin Ryabitsev wrote:
> On Fri, Oct 10, 2025 at 03:34:52PM +0100, Lee Jones wrote:
> > > Next question is -- have you recently stopped adding Link: tags to your
> > > commits? :)
> > 
> > Oooo, yes!  Yes, I have!
> > 
> > Why would that make a difference?
> 
> When patches have been altered by the maintainer, we can no longer match them
> by git-patch-id.

Which is the primary reason to keep the Link: stuff.  Many maintainers
manually change patches to fix up minor things all the time, and without
the Link: it's a major pain to find (the LF sponsored a whole project
just to do the backwards mapping for many years, but no one used it...)

> In the past, when we found a Link: trailer, we could still
> match their provenance by message-id, but if that is gone, we can no longer
> fall back to that. I am working on making the "ty" mechanism being less
> dependent on that -- hopefully the master branch should become more useful to
> you again in the near future.

message-id is important to track somehow, we need that link.

thanks,

greg k-h

Re: b4: ty: User-flow regression

[Lee Jones]

On Sat, 11 Oct 2025, Greg KH wrote:

> On Fri, Oct 10, 2025 at 10:37:22AM -0400, Konstantin Ryabitsev wrote:
> > On Fri, Oct 10, 2025 at 03:34:52PM +0100, Lee Jones wrote:
> > > > Next question is -- have you recently stopped adding Link: tags to your
> > > > commits? :)
> > > 
> > > Oooo, yes!  Yes, I have!
> > > 
> > > Why would that make a difference?
> > 
> > When patches have been altered by the maintainer, we can no longer match them
> > by git-patch-id.
> 
> Which is the primary reason to keep the Link: stuff.  Many maintainers
> manually change patches to fix up minor things all the time, and without
> the Link: it's a major pain to find (the LF sponsored a whole project
> just to do the backwards mapping for many years, but no one used it...)
> 
> > In the past, when we found a Link: trailer, we could still
> > match their provenance by message-id, but if that is gone, we can no longer
> > fall back to that. I am working on making the "ty" mechanism being less
> > dependent on that -- hopefully the master branch should become more useful to
> > you again in the near future.
> 
> message-id is important to track somehow, we need that link.

It turns out that going back to manually thanking contributors is too
much of a regression for me ATM.  For now at least, against Linus'
wishes (sadly), I'm putting Link:s back in.

-- 
Lee Jones [李琼斯]

Re: b4: ty: User-flow regression

[Vlastimil Babka (SUSE)]

On 10/21/25 12:56, Lee Jones wrote:
> On Sat, 11 Oct 2025, Greg KH wrote:
> 
>> On Fri, Oct 10, 2025 at 10:37:22AM -0400, Konstantin Ryabitsev wrote:
>> > On Fri, Oct 10, 2025 at 03:34:52PM +0100, Lee Jones wrote:
>> > > > Next question is -- have you recently stopped adding Link: tags to your
>> > > > commits? :)
>> > > 
>> > > Oooo, yes!  Yes, I have!
>> > > 
>> > > Why would that make a difference?
>> > 
>> > When patches have been altered by the maintainer, we can no longer match them
>> > by git-patch-id.
>> 
>> Which is the primary reason to keep the Link: stuff.  Many maintainers
>> manually change patches to fix up minor things all the time, and without
>> the Link: it's a major pain to find (the LF sponsored a whole project
>> just to do the backwards mapping for many years, but no one used it...)
>> 
>> > In the past, when we found a Link: trailer, we could still
>> > match their provenance by message-id, but if that is gone, we can no longer
>> > fall back to that. I am working on making the "ty" mechanism being less
>> > dependent on that -- hopefully the master branch should become more useful to
>> > you again in the near future.
>> 
>> message-id is important to track somehow, we need that link.
> 
> It turns out that going back to manually thanking contributors is too
> much of a regression for me ATM.  For now at least, against Linus'
> wishes (sadly), I'm putting Link:s back in.
 
Linus later said he would tolerate them with the https://patch.msgid.link
domain:

https://lore.kernel.org/all/CAHk-=wj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR+=Vtw@mail.gmail.com/

Re: b4: ty: User-flow regression

[Lee Jones]

On Tue, 21 Oct 2025, Vlastimil Babka (SUSE) wrote:

> On 10/21/25 12:56, Lee Jones wrote:
> > On Sat, 11 Oct 2025, Greg KH wrote:
> > 
> >> On Fri, Oct 10, 2025 at 10:37:22AM -0400, Konstantin Ryabitsev wrote:
> >> > On Fri, Oct 10, 2025 at 03:34:52PM +0100, Lee Jones wrote:
> >> > > > Next question is -- have you recently stopped adding Link: tags to your
> >> > > > commits? :)
> >> > > 
> >> > > Oooo, yes!  Yes, I have!
> >> > > 
> >> > > Why would that make a difference?
> >> > 
> >> > When patches have been altered by the maintainer, we can no longer match them
> >> > by git-patch-id.
> >> 
> >> Which is the primary reason to keep the Link: stuff.  Many maintainers
> >> manually change patches to fix up minor things all the time, and without
> >> the Link: it's a major pain to find (the LF sponsored a whole project
> >> just to do the backwards mapping for many years, but no one used it...)
> >> 
> >> > In the past, when we found a Link: trailer, we could still
> >> > match their provenance by message-id, but if that is gone, we can no longer
> >> > fall back to that. I am working on making the "ty" mechanism being less
> >> > dependent on that -- hopefully the master branch should become more useful to
> >> > you again in the near future.
> >> 
> >> message-id is important to track somehow, we need that link.
> > 
> > It turns out that going back to manually thanking contributors is too
> > much of a regression for me ATM.  For now at least, against Linus'
> > wishes (sadly), I'm putting Link:s back in.
>  
> Linus later said he would tolerate them with the https://patch.msgid.link
> domain:
> 
> https://lore.kernel.org/all/CAHk-=wj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR+=Vtw@mail.gmail.com/

Okay, this works.  Looks like b4 now supports that in `master` as:

52d380965c71 ("Set default linkmask to patch.msgid.link")

-- 
Lee Jones [李琼斯]