bug#72059: [PATCH] Ensure that git diffs without signature (--) are properly identified

[Luis Henriques <henrix@camandro.org>]

Hi Robert!

(First of all, thank you for your review!)

On Thu, Jul 11 2024, Robert Pluim wrote:

>>>>>> On Thu, 11 Jul 2024 13:20:32 +0100, Luis Henriques <henrix@camandro.org> said:
>
>     Luis> Hi!
>     Luis> [Resending as I don't see message in the list after a few hours.]
>
> I see both those messages. There is moderation for unsubscribed users,
> so sometimes there is lag.

Yeah, sorry.  I saw both hitting the list pretty much at the same time.  I
guess I was just too eager on getting it there.

>
>     Luis> I'd like to have git-format-patch diffs to be properly identified when I'm
>     Luis> using Gnus to read mailing-lists.  It mostly works fine, *if* the
>     Luis> (inlined) patches include a signature at the end ('--').  If the signature
>     Luis> is missing then the patch isn't identified as such.
>
>     Luis> Since all the other diff formats in mm-uu-type-alist don't have the
>     Luis> 'end-point' I thought it would be fine to also remove it from the
>     Luis> 'git-format-patch'.
>
> git-format-patch only produces patches like that if you pass it
> '--no-signature', I think.

Or you may just set 'format.signature' to an empty string in your config,
which is what I have been using almost since day one.  This will prevent
git from leaking it's version.

>     Luis> The issue I'm trying to fix can be easily seen in Gnus by comparing two
>     Luis> emails with the following message-ids from the emacs-devel@gnu.org
>     Luis> mailing-list:
>
>     Luis>   87v81dmhxi.fsf@orpheu.olymp
>
> That one actually looks like just 'git diff' rather than 'git format-patch'

I didn't go check, but if I had to guess, 'git format-patch' actually uses
'git diff' for generating the diff (with stats) and adds a signature at
the end (if configured to do so).

Anyway, I always send patches without git signature, generated with 'git
format-patch' and (most of the time) sent with 'git send-email'.  And
those are never identified as patches.

> Iʼm trying to work out the benefit here compared to the status quo vs
> the risk of breaking something. If Gnus doesnʼt identify such messages
> as containing patches, you donʼt get the in-article buttons, but you
> can still pipe the message to 'git apply'.

Right, the only benefit is just the extra eye-candy stuff.

> Also, how does this work for messages containing multiple patches? Is
> detection of just the start of each patch enough?

Do you have an example where this happens?  I don't think I ever saw an
email with two inlined patches.  But obviously, with this patch applied,
everything from the "^diff --git " up to the end of the email will be a
diff.  Just like everything after "^=== modified file " or "^Index: " will
be a diff.

> Maybe adding a new detection method would be better?

The problem I see with that is that this new detection method will
necessarily overlap with the 'git-format-patch' in mm-uu-type-alist.
Won't it simply shadow it, and will always be used?

Cheers,
-- 
Luís