[RFC PATCH v2 0/3] format-patch --complete / am --exact

[Vegard Nossum <vegard.nossum@oracle.com>]

[I'm intentionally keeping the recipient list short to avoid hitting
the Oracle spam filter on outgoing email, hopefully everybody on the
git side who is interested will receive this via the mailing list and
I will link this submission from the workflows list too.]

Background:

There seems to be a consensus in the Linux kernel development community
that tracking patches, patchsets, reviews, and discussion of said patches
is too difficult. One big problem is that there is often no reference to
the email discussion in git history once the patch has been merged.

In order to simplify the tracking of patches, I proposed in [1] that we
include enough metadata about a patch to reconstruct the commit SHA1s
when emailing patches; this means that, assuming a patchset is based on
a publicly available parent SHA1, we can track email patches in git and
use the git SHA1 as a stable reference to a particular submission or its
corresponding discussion. I basically view this as a foundation on which
we can build a richer kernel development experience without sacrificing
the current email-based workflow.

Since I started working on this feature, I also realised that 'git am'
already has a mechanism to amend changelogs with a reference to the
"Message-Id" of the email of a patch using the --message-id flag, and
while this should IMHO be used a lot more for the kernel, it does not
completely offset the utility of these patches.

I'm sending out an early v2 to get more feedback on the implementation,
exact choice of flags and terminology (--exact, --complete, "metadata",
etc.), changelogs.

Changes since v1:
 - moved metadata to the bottom of the diff
 - fixes to pass existing tests (0023, 3403, 4150, 4256, 5100)
 - handles format=flowed (best effort)
 - better changelogs
 - documentation
 - new tests

Todo:
 - 'git am --no-exact' _with_ known metadata could append the original
   sha1 (and/or mail reference) to the changelog
 - UTF-8/non-ASCII encodings
 - 'git am' error handling (e.g. wrong base)
 - more tests: --range-diff, --base=auto, 'am -s', etc.
 - GPG-signed commits [2]

Out of scope for now:
 - Ted's suggestion of a new flag for the base [3]
 - in-transit mangling
 - minisigs
 - empty commits and/or merge commits [4]

[1] https://lore.kernel.org/workflows/b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com/
[2] https://lore.kernel.org/workflows/56664222-6c29-09dc-ef78-7b380b113c4a@oracle.com/
[3] https://lore.kernel.org/workflows/20191017144708.GI25548@mit.edu/
[4] https://lore.kernel.org/workflows/xmqqeezc83i6.fsf@gitster-ct.c.googlers.com/