[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@xxxxxxxxxx/ [2] https://lore.kernel.org/workflows/56664222-6c29-09dc-ef78-7b380b113c4a@xxxxxxxxxx/ [3] https://lore.kernel.org/workflows/20191017144708.GI25548@xxxxxxx/ [4] https://lore.kernel.org/workflows/xmqqeezc83i6.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/
