b4: ty: User-flow regression

[Lee Jones <lee@kernel.org>]

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 [李琼斯]