b4: ty: User-flow regression
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.
Signature · 1 line
Lee Jones [李琼斯]
Quoted 10 lines · Lee Jones
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 doDoh! 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
Quoted 2 lines · Konstantin Ryabitsev
Quoted 1 line · Lee Jones
The that I'm highlighting occurs when changes have to be made to the
issue ^
Quoted 8 lines
Quoted 8 lines
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
Quoted 4 lines
Quoted 1 line
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
Signature · 1 line
Lee Jones [李琼斯]
Quoted 12 lines · Lee Jones
Quoted 9 lines
Quoted 6 lines
Auto-thankanating commits in for-mfd-next
Found 5 of your commits since 1.day
Calculating patch hashes, may take a moment...
Nothing to doDoh! 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:
Quoted 7 lines
$ 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
Quoted 16 lines · Konstantin Ryabitsev
Quoted 15 lines · Lee Jones
Quoted 9 lines
Quoted 6 lines
Auto-thankanating commits in for-mfd-next
Found 5 of your commits since 1.day
Calculating patch hashes, may take a moment...
Nothing to doDoh! 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>
Quoted 7 lines
Quoted 4 lines
$ git config --list | grep diff diff.wserrorhighlight=all diff.colormoved=zebra merge.conflictstyle=diff3Next question is -- have you recently stopped adding Link: tags to your commits? :)
Oooo, yes! Yes, I have!
Why would that make a difference?
Signature · 1 line
Lee Jones [李琼斯]
Quoted 6 lines · Lee Jones
Quoted 2 lines
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
Quoted 6 lines · Konstantin Ryabitsev
Quoted 5 lines · Lee Jones
Quoted 2 lines
Next question is -- have you recently stopped adding Link: tags to your commits? :)
Oooo, yes! Yes, I have!
Quoted 8 lines
Quoted 1 line
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!
Signature · 1 line
Lee Jones [李琼斯]
Quoted 10 lines · Konstantin Ryabitsev
Quoted 6 lines · Lee Jones
Quoted 2 lines
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...)
Quoted 5 lines
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
Quoted 17 lines · Greg KH
Quoted 10 lines · Konstantin Ryabitsev
Quoted 6 lines · Lee Jones
Quoted 2 lines
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...)
Quoted 7 lines
Quoted 5 lines
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.
Signature · 1 line
Lee Jones [李琼斯]
Quoted 25 lines · Lee Jones
Quoted 23 lines · Greg KH
Quoted 10 lines · Konstantin Ryabitsev
Quoted 6 lines · Lee Jones
Quoted 2 lines
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...)
Quoted 5 lines
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.
Quoted 5 lines
Quoted 1 line
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/
Quoted 28 lines · Vlastimil Babka (SUSE)
Quoted 27 lines · Lee Jones
Quoted 24 lines · Greg KH
Quoted 10 lines · Konstantin Ryabitsev
Quoted 6 lines · Lee Jones
Quoted 2 lines
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...)
Quoted 5 lines
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.
Quoted 8 lines
Quoted 3 lines
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")
Signature · 1 line
Lee Jones [李琼斯]