RFC: using supersedes: trailer to indicate patch/series revision flow

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

Hi, all:

The only mechanism we currently have for patch/series versioning is 
subject suffixes. I think it would be useful to have a way to more 
explicitly mark that a series obsoletes a previous version, and I 
propose this is done with a `supersedes:` trailer at the end of the 
cover letter or in the first patch of the series:

E.g.:

Initial patch:

---8<---
From: Dev Eloper <dev.eloper@example.com>
Message-Id: <1572991351-86061-1-git-send-email-dev.eloper@example.com>
Subject: [PATCH] Change foo

Foo is no good. Use Bar.

Signed-off-by: Dev Eloper <dev.eloper@example.com>
---
  foo | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/foo b/foo
...

base-commit: 23fdb198ae81f47a574296dab5167c5e136a02ba
-- 
2.24.0
---8<---

Follow-up patch:

---8<---
From: Dev Eloper <dev.eloper@example.com>
Message-Id: <1572991352-86062-2-git-send-email-dev.eloper@example.com>
Subject: [PATCH,v2] Change foo

Foo is no good. Use Bar. Also use baz.

Signed-off-by: Dev Eloper <dev.eloper@example.com>
---
  foo | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/foo b/foo
...

supersedes: <1572991351-86061-1-git-send-email-dev.eloper@example.com>
base-commit: 23fdb198ae81f47a574296dab5167c5e136a02ba
-- 
2.24.0
---8<---

Questions:

1. Should this be exposed via git-format-patch flags, or just used by 
    specialized tooling?
2. Should supersedes: link to the previous version of the patch, or the 
    first ever version of the patch? I am leaning towards the latter, 
    even though in this case the message-id largely becomes identical in 
    usage to Gerrit's Change-Id.
3. Should the supersedes trailer have:
    a. message-id without brackets
    b. message-id with brackets
    c. https://lore.kernel.org/r/message-id
    My preference is b, to match with The Message-Id header usage.


-K