On Wed, 16 Aug 2023 at 12:25:13 +0200, Guillem Jover wrote: > Here's what a git format-patch patch looks like: > > ,--- > From 9767e87d08803d78208464be3652a9231b6b08e3 Mon Sep 17 00:00:00 2001 > From: Guillem Jover <guil...@hadrons.org> > Date: Thu, 10 Aug 2023 20:31:02 +0200
One particularly popular tool for managing debian/patches is gbp pq, which removes the leading "From " line, and the trailing "-- " and git version, in an effort to normalize the patch content in a way that will reduce spurious changes when the patch series is rebased. I think ideally the Patch Tagging Guidelines should *allow* the first line to start with "From ", with no semantic meaning, so that maintainers of simple packages can drop `git format-patch` output directly into debian/patches; but should not *require* that first line, so that the current output of `gbp pq export` is considered to be equally correct. I personally think the extent to which git has "won", both upstream and in Debian package maintenance, means that the Patch Tagging Guidelines should be encouraging the git-like style as primary, with From/Date/Subject in a header and all Debian-specific fields in a trailing pseudo-header, the same layout that's familiar for Signed-off-by and similar tags used by many upstream developers: From <anything here, optional, ignored> From: ... Date: ... Subject: <short description> <long description> <more long description> Signed-off-by: ... Bug: https://... Origin: vendor, Debian Forwarded: https://... --- <the actual diff> That would encourage interoperability with how patches are represented and tagged (formally or informally) in many non-Debian environments. When interacting with developers of non-Debian-based distributions (for example one of my $work projects is Arch-based), I'd like to be able to point to DEP-3 and say "consider using this format" with a minimum of what developers of the other project would consider to be weird Debianisms: concepts like tracking whether a patch is upstreamable in principle, and how far it has got in actually going upstream, are equally useful for any downstream distribution. Emphasizing the familiar git-like format in preference to deb822 would be a step in that direction. smcv