{"thread":{"id":"52044","subject":"email as a bona fide git transport","startedAt":"2019-10-16T10:23:10Z","lastAt":"2019-10-22T19:01:31Z","messageCount":36,"participants":["Vegard Nossum","Willy Tarreau","Pratyush Yadav","Santiago Torres Arias","Jonathan Nieder","Junio C Hamano","Theodore Y. Ts'o","Steven Rostedt","Greg KH","Konstantin Ryabitsev","Eric Wong","Nicolas Belouin","Laurent Pinchart"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"384172","messageId":"b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com","threadId":"52044","inReplyTo":null,"subject":"email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-16T10:22:54Z","receivedAt":"2019-10-16T10:23:10Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"(cross-posted to git, LKML, and the kernel workflows mailing lists.)\n\nHi all,\n\nI've been following Konstantin Ryabitsev's quest for better development\nand communication tools for the kernel [1][2][3], and I would like to\npropose a relatively straightforward idea which I think could bring a\nlot to the table.\n\nStep 1:\n\n* git send-email needs to include parent SHA1s and generally all the\n information needed to perfectly recreate the commit when applied so\n that all the SHA1s remain the same\n\n* git am (or an alternative command) needs to recreate the commit\n perfectly when applied, including applying it to the correct parent\n\nHaving these two will allow a perfect mapping between email and git;\nessentially email just becomes a transport for git. There are a lot of\nadvantages to this, particularly that you have a stable way to refer to\na patch or commit (despite it appearing on a mailing list), and there\nis no need for \"changeset IDs\" or whatever, since you can just use the\ngit SHA1 which is unique, unambiguous, and stable.\n\nAs a rough proof of concept I've attached 3 git patches which implement\nthis. There are issues to work out like exact format, encodings, mail\nmangling, error handling, etc., but hopefully the git community can\nhelp out here. (Improvement suggestions are welcome!)\n\nStep 2:\n\n* A bot that follows LKML (and other lists) and imports patchsets into\n a git repository hosted on git.kernel.org\n\n* The bot can add git notes with URLs to lore (and/or other mailing\n list archives) and store them in e.g. refs/notes/lore,\n refs/notes/lkml, etc.\n\n (For those who don't use git notes yet: they are essentially small\n bits of information you can add to a commit without changing its SHA1,\n and you can configure tools like 'git log' to show these at the bottom\n of a commit. Notes can also exist in a repo completely separate from\n the commits they attach data to, so there is _zero_ overhead for those\n who don't want to use this.)\n\n* Maintainers can either pull patchsets directly from this bot-\n maintained repo OR they can continue to apply patches from their inbox\n (the result should be the same either way) OR they can continue in the\n old-style process (at least for a while) and just not have the\n benefits of the new process.\n\nStep 3:\n\n* Instead of describing a patchset in a separate introduction email, we\n can create a merge commit between the parent of the first commit in\n the series and the last and put the patchset description in the merge\n commit [5]. This means the patchset description also gets to be part\n of git history.\n\n (This would require support for git send-email/am to be able to send\n and apply merge commits -- at least those which have the same tree as\n one of the parents. This is _not_ yet supported in my proposed git\n patches.)\n\n* stable SHA1s means we can refer to previous versions of a patchset by\n SHA1 rather than archive links. I propose a new changelog tag for\n this, maybe \"Previous:\" or maybe even a full list of \"v1:\", \"v2:\",\n etc. with a SHA1 or ref. Note that these SHA1s do *not* need to exist\n in Linus's repo, but those who want can pull those branches from the\n bot-maintained repo on git.kernel.org.\n\nAdvantages:\n\n- we can keep using email to post patches/patchsets\n\n- the process is opt-in (but should be encouraged) for both authors and\n maintainers, and the transition can happen over time\n\n- there is a central repo for convenience, but it is not necessary for\n development to happen and is not a single point of failure -- it's\n more like Linus's repo and can be moved or even replicated from\n scratch by somebody else simply by having mailing list archives\n\n- allows quick lookup of patch/patchset <-> email discussion within git\n\n- allows diffing between versions of a single logical patchset\n\n- patchset descriptions naturally become part of the changelog that ends\n up in Linus's tree\n\nDisadvantages:\n\n- requires patching git\n\n- requires a bot to continuously create branches for patchsets sent to\n mailing lists\n\n- increased storage/bandwidth for git.kernel.org (?)\n\n- may need a couple of new wrapper scripts to automate patchset\n construction/versioning\n\nThoughts?\n\n\nVegard\n\nPS: Eric Wong described something that comes quite close to this idea, \nbut AFAICT without actually recreating commits exactly. I've included \nthe link for completeness. [4]\n\n\n[1]: https://lwn.net/Articles/793037/ \"Ryabitsev: Patches carved into\ndeveloper sigchains\"\n\n[2]: https://lwn.net/Articles/799134/ \"Defragmenting the kernel\ndevelopment process\"\n\n[3]: \nhttps://lore.kernel.org/workflows/20190924182536.GC6041@hmswarspite.think-freely.org/\n\n[4]: https://lore.kernel.org/workflows/20191008003931.y4rc2dp64gbhv5ju@dcvr/\n\n[5]: To create this merge commit one could use something like this (bash):\n\n# usage: patchset BASE [PREVIOUS_VERSION]\npatchset () {\n start=$1\n prev=$2\n\n # construct tentative commit message\n commit_editmsg=\"$(git rev-parse --git-dir)/COMMIT_EDITMSG\"\n (\n if [ -z \"$prev\" ]\n then\n echo 'Patchset title'\n echo\n echo Commits:\n echo\n git log --oneline $start..HEAD\n else\n git show --format=format:%B --no-patch $prev\n echo Previous-version: $(git rev-parse $prev)\n fi\n ) > \"${commit_editmsg}\"\n\n ${EDITOR} \"${commit_editmsg}\"\n\n merge=$(git commit-tree -p $start -p HEAD -F \"${commit_editmsg}\" \n$(git rev-parse HEAD^{tree}))\n echo $merge\n}\n\nThis will open the editor to edit the patchset description and create a\nmerge commit that encompasses the patches in the patchset (use sha1^- to\nview the patches in it).\n\n\nFrom 622a0469a4970c5daac0c0323e2d6a77b3bebbdb Mon Sep 17 00:00:00 2001\nFrom: Vegard Nossum \nDate: Sat, 5 Oct 2019 16:15:59 +0200\nSubject: [PATCH 1/3] format-patch: add --complete\n\nInclude the raw commit data between the changelog and the diffstat.\nThis will allow 'git am' to reconstruct the commit exactly to the point\nwhere the sha1 will be the same.\n\nSigned-off-by: Vegard Nossum \n---\ncommit 622a0469a4970c5daac0c0323e2d6a77b3bebbdb\ntree 8f09d9d6ed78f8617b2fe54fe9712990ba808546\nparent 108b97dc372828f0e72e56bbb40cae8e1e83ece6\nauthor Vegard Nossum 1570284959 +0200\ncommitter Vegard Nossum 1571219301 +0200\n\n---\n builtin/log.c | 12 ++++++++++++\n log-tree.c | 17 +++++++++++++++++\n revision.h | 3 ++-\n 3 files changed, 31 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/log.c b/builtin/log.c\nindex c4b35fdaf9..81c1164ae5 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -1545,6 +1545,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \tchar *branch_name = NULL;\n \tchar *base_commit = NULL;\n \tstruct base_tree_info bases;\n+\tint complete = 0;\n \tint show_progress = 0;\n \tstruct progress *progress = NULL;\n \tstruct oid_array idiff_prev = OID_ARRAY_INIT;\n@@ -1622,6 +1623,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \t\t\t N_(\"add a signature\")),\n \t\tOPT_STRING(0, \"base\", &base_commit, N_(\"base-commit\"),\n \t\t\t N_(\"add prerequisite tree info to the patch series\")),\n+\t\tOPT_BOOL(0, \"complete\", &complete,\n+\t\t\t N_(\"include all the information necessary to reconstruct commit exactly\")),\n \t\tOPT_FILENAME(0, \"signature-file\", &signature_file,\n \t\t\t\tN_(\"add a signature from a file\")),\n \t\tOPT__QUIET(&quiet, N_(\"don't print the patch filenames\")),\n@@ -1905,6 +1908,15 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \t\tprepare_bases(&bases, base, list, nr);\n \t}\n \n+\tif (complete) {\n+\t\t/*\n+\t\t * We need the commit buffer so that we can output the exact\n+\t\t * sequence of bytes that gets hashed as part of a commit.\n+\t\t */\n+\t\tsave_commit_buffer = 1;\n+\t\trev.show_raw_buffer = 1;\n+\t}\n+\n \tif (in_reply_to || thread || cover_letter)\n \t\trev.ref_message_ids = xcalloc(1, sizeof(struct string_list));\n \tif (in_reply_to) {\ndiff --git a/log-tree.c b/log-tree.c\nindex 923a299e70..2c9788b25a 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -774,6 +774,22 @@ void show_log(struct rev_info *opt)\n \n \t\tmemcpy(&diff_queued_diff, &dq, sizeof(diff_queued_diff));\n \t}\n+\n+\tif (opt->show_raw_buffer) {\n+\t\tconst char *buffer = get_commit_buffer(commit, NULL);\n+\t\tconst char *subject;\n+\n+\t\tfprintf(opt->diffopt.file, \"---\\n\");\n+\t\tfprintf(opt->diffopt.file, \"commit %s\\n\", oid_to_hex(&commit->object.oid));\n+\n+\t\t/*\n+\t\t * TODO: hex-encode to avoid mailer mangling?\n+\t\t */\n+\t\tif (find_commit_subject(buffer, &subject))\n+\t\t\tfprintf(opt->diffopt.file, \"%.*s\", (int) (subject - buffer), buffer);\n+\t\telse\n+\t\t\tfprintf(opt->diffopt.file, \"%s\", buffer);\n+\t}\n }\n \n int log_tree_diff_flush(struct rev_info *opt)\n@@ -791,6 +807,7 @@ int log_tree_diff_flush(struct rev_info *opt)\n \n \tif (opt->loginfo && !opt->no_commit_id) {\n \t\tshow_log(opt);\n+\n \t\tif ((opt->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT) &&\n \t\t opt->verbose_header &&\n \t\t opt->commit_format != CMIT_FMT_ONELINE &&\ndiff --git a/revision.h b/revision.h\nindex 4134dc6029..5297dc9f3c 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -190,7 +190,8 @@ struct rev_info {\n \t\t\tuse_terminator:1,\n \t\t\tmissing_newline:1,\n \t\t\tdate_mode_explicit:1,\n-\t\t\tpreserve_subject:1;\n+\t\t\tpreserve_subject:1,\n+\t\t\tshow_raw_buffer:1;\n \tunsigned int\tdisable_stdin:1;\n \t/* --show-linear-break */\n \tunsigned int\ttrack_linear:1,\n-- \n2.23.0.718.g3120370db8\n\n\n\nFrom 51bb531eb57320caf3761680ebf77c25b89b3719 Mon Sep 17 00:00:00 2001\nFrom: Vegard Nossum \nDate: Wed, 16 Oct 2019 02:04:08 +0200\nSubject: [PATCH 2/3] mailinfo: collect commit metadata from mail\n\nSigned-off-by: Vegard Nossum \n---\ncommit 51bb531eb57320caf3761680ebf77c25b89b3719\ntree f3a3141f7d3f706d8ca60cdc1e1cde5aa2cc927a\nparent 622a0469a4970c5daac0c0323e2d6a77b3bebbdb\nauthor Vegard Nossum 1571184248 +0200\ncommitter Vegard Nossum 1571219301 +0200\n\n---\n builtin/am.c | 2 +-\n builtin/mailinfo.c | 11 +++++++---\n mailinfo.c | 55 +++++++++++++++++++++++++++++++++++++++++++++-\n mailinfo.h | 4 +++-\n 4 files changed, 66 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/am.c b/builtin/am.c\nindex 8181c2aef3..4190383bba 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -1159,7 +1159,7 @@ static int parse_mail(struct am_state *state, const char *mail)\n \n \tmi.input = xfopen(mail, \"r\");\n \tmi.output = xfopen(am_path(state, \"info\"), \"w\");\n-\tif (mailinfo(&mi, am_path(state, \"msg\"), am_path(state, \"patch\")))\n+\tif (mailinfo(&mi, am_path(state, \"msg\"), am_path(state, \"patch\"), am_path(state, \"meta\")))\n \t\tdie(\"could not parse patch\");\n \n \tfclose(mi.input);\ndiff --git a/builtin/mailinfo.c b/builtin/mailinfo.c\nindex cfb667a594..f3f9aabd97 100644\n--- a/builtin/mailinfo.c\n+++ b/builtin/mailinfo.c\n@@ -16,7 +16,7 @@ int cmd_mailinfo(int argc, const char **argv, const char *prefix)\n \tconst char *def_charset;\n \tstruct mailinfo mi;\n \tint status;\n-\tchar *msgfile, *patchfile;\n+\tchar *msgfile, *patchfile, *metafile;\n \n \tsetup_mailinfo(&mi);\n \n@@ -47,7 +47,7 @@ int cmd_mailinfo(int argc, const char **argv, const char *prefix)\n \t\targc--; argv++;\n \t}\n \n-\tif (argc != 3)\n+\tif (argc < 3 || argc > 4)\n \t\tusage(mailinfo_usage);\n \n \tmi.input = stdin;\n@@ -56,10 +56,15 @@ int cmd_mailinfo(int argc, const char **argv, const char *prefix)\n \tmsgfile = prefix_filename(prefix, argv[1]);\n \tpatchfile = prefix_filename(prefix, argv[2]);\n \n-\tstatus = !!mailinfo(&mi, msgfile, patchfile);\n+\tmetafile = NULL;\n+\tif (argc == 4)\n+\t\tmetafile = prefix_filename(prefix, argv[3]);\n+\n+\tstatus = !!mailinfo(&mi, msgfile, patchfile, metafile);\n \tclear_mailinfo(&mi);\n \n \tfree(msgfile);\n \tfree(patchfile);\n+\tfree(metafile);\n \treturn status;\n }\ndiff --git a/mailinfo.c b/mailinfo.c\nindex b395adbdf2..50e2c685df 100644\n--- a/mailinfo.c\n+++ b/mailinfo.c\n@@ -825,6 +825,40 @@ static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)\n \treturn 0;\n }\n \n+/*\n+ * returns non-0 when we're done handling metadata\n+ */\n+static int handle_meta(struct mailinfo *mi, const struct strbuf *line)\n+{\n+\tif (mi->meta_stage == 0) {\n+\t\t/*\n+\t\t * Swallow the first patch break and continue handling meta\n+\t\t */\n+\t\tif (patchbreak(line)) {\n+\t\t\t++mi->meta_stage;\n+\t\t\treturn 0;\n+\t\t}\n+\n+\t\treturn 1;\n+\t}\n+\n+\tif (mi->meta_stage == 1) {\n+\t\t/*\n+\t\t * Check that the first line is \"commit \", punt if not\n+\t\t */\n+\t\tif (!starts_with(line->buf, \"commit \"))\n+\t\t\treturn 1;\n+\n+\t\t++mi->meta_stage;\n+\t}\n+\n+\tif (patchbreak(line))\n+\t\treturn 1;\n+\n+\tstrbuf_addbuf(&mi->meta_text, line);\n+\treturn 0;\n+}\n+\n static void handle_patch(struct mailinfo *mi, const struct strbuf *line)\n {\n \tfwrite(line->buf, 1, line->len, mi->patchfile);\n@@ -840,6 +874,11 @@ static void handle_filter(struct mailinfo *mi, struct strbuf *line)\n \t\tmi->filter_stage++;\n \t\t/* fallthrough */\n \tcase 1:\n+\t\tif (!handle_meta(mi, line))\n+\t\t\tbreak;\n+\t\tmi->filter_stage++;\n+\t\t/* fallthrough */\n+\tcase 2:\n \t\thandle_patch(mi, line);\n \t\tbreak;\n \t}\n@@ -1145,9 +1184,10 @@ static void handle_info(struct mailinfo *mi)\n \tfprintf(mi->output, \"\\n\");\n }\n \n-int mailinfo(struct mailinfo *mi, const char *msg, const char *patch)\n+int mailinfo(struct mailinfo *mi, const char *msg, const char *patch, const char *meta)\n {\n \tFILE *cmitmsg;\n+\tFILE *metafile;\n \tint peek;\n \tstruct strbuf line = STRBUF_INIT;\n \n@@ -1163,6 +1203,14 @@ int mailinfo(struct mailinfo *mi, const char *msg, const char *patch)\n \t\treturn -1;\n \t}\n \n+\tmetafile = fopen(meta, \"w\");\n+\tif (!metafile) {\n+\t\tperror(meta);\n+\t\tfclose(mi->patchfile);\n+\t\tfclose(cmitmsg);\n+\t\treturn -1;\n+\t}\n+\n \tmi->p_hdr_data = xcalloc(MAX_HDR_PARSED, sizeof(*(mi->p_hdr_data)));\n \tmi->s_hdr_data = xcalloc(MAX_HDR_PARSED, sizeof(*(mi->s_hdr_data)));\n \n@@ -1184,6 +1232,9 @@ int mailinfo(struct mailinfo *mi, const char *msg, const char *patch)\n \tfclose(cmitmsg);\n \tfclose(mi->patchfile);\n \n+\tfwrite(mi->meta_text.buf, 1, mi->meta_text.len, metafile);\n+\tfclose(metafile);\n+\n \thandle_info(mi);\n \tstrbuf_release(&line);\n \treturn mi->input_error;\n@@ -1210,8 +1261,10 @@ void setup_mailinfo(struct mailinfo *mi)\n \tstrbuf_init(&mi->email, 0);\n \tstrbuf_init(&mi->charset, 0);\n \tstrbuf_init(&mi->log_message, 0);\n+\tstrbuf_init(&mi->meta_text, 0);\n \tstrbuf_init(&mi->inbody_header_accum, 0);\n \tmi->header_stage = 1;\n+\tmi->meta_stage = 0;\n \tmi->use_inbody_headers = 1;\n \tmi->content_top = mi->content;\n \tgit_config(git_mailinfo_config, mi);\ndiff --git a/mailinfo.h b/mailinfo.h\nindex 79b1d6774e..89386103bd 100644\n--- a/mailinfo.h\n+++ b/mailinfo.h\n@@ -31,16 +31,18 @@ struct mailinfo {\n \tint patch_lines;\n \tint filter_stage; /* still reading log or are we copying patch? */\n \tint header_stage; /* still checking in-body headers? */\n+\tint meta_stage;\n \tstruct strbuf inbody_header_accum;\n \tstruct strbuf **p_hdr_data;\n \tstruct strbuf **s_hdr_data;\n \n \tstruct strbuf log_message;\n+\tstruct strbuf meta_text;\n \tint input_error;\n };\n \n void setup_mailinfo(struct mailinfo *);\n-int mailinfo(struct mailinfo *, const char *msg, const char *patch);\n+int mailinfo(struct mailinfo *, const char *msg, const char *patch, const char *meta);\n void clear_mailinfo(struct mailinfo *);\n \n #endif /* MAILINFO_H */\n-- \n2.23.0.718.g3120370db8\n\n\n\nFrom 3120370db888889f32e07a082edb4722db8feef1 Mon Sep 17 00:00:00 2001\nFrom: Vegard Nossum \nDate: Wed, 16 Oct 2019 02:36:18 +0200\nSubject: [PATCH 3/3] am: add --exact\n\nThis uses exact metadata when creating the commit object, hopefully\nreconstructing the commit with the exact same SHA1.\n\nSigned-off-by: Vegard Nossum \n---\ncommit 3120370db888889f32e07a082edb4722db8feef1\ntree 61b7556f06fd6fcb0f4a43940ec0cbc29ccf1bcc\nparent 51bb531eb57320caf3761680ebf77c25b89b3719\nauthor Vegard Nossum 1571186178 +0200\ncommitter Vegard Nossum 1571219301 +0200\n\n---\n builtin/am.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++-----\n 1 file changed, 94 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin/am.c b/builtin/am.c\nindex 4190383bba..069a625895 100644\n--- a/builtin/am.c\n+++ b/builtin/am.c\n@@ -118,6 +118,7 @@ struct am_state {\n \tint allow_rerere_autoupdate;\n \tconst char *sign_commit;\n \tint rebasing;\n+\tint exact;\n };\n \n /**\n@@ -399,6 +400,8 @@ static void am_load(struct am_state *state)\n \n \tstate->rebasing = !!file_exists(am_path(state, \"rebasing\"));\n \n+\tstate->exact = read_state_file(&sb, state, \"exact\", 1);\n+\n \tstrbuf_release(&sb);\n }\n \n@@ -1005,6 +1008,8 @@ static void am_setup(struct am_state *state, enum patch_format patch_format,\n \telse\n \t\twrite_state_text(state, \"applying\", \"\");\n \n+\twrite_state_bool(state, \"exact\", state->exact);\n+\n \tif (!get_oid(\"HEAD\", &curr_head)) {\n \t\twrite_state_text(state, \"abort-safety\", oid_to_hex(&curr_head));\n \t\tif (!state->rebasing)\n@@ -1548,19 +1553,88 @@ static int fall_back_threeway(const struct am_state *state, const char *index_pa\n */\n static void do_commit(const struct am_state *state)\n {\n+\tstruct object_id meta_commit = {};\n+\tstruct object_id meta_tree = {};\n+\n \tstruct object_id tree, parent, commit;\n \tconst struct object_id *old_oid;\n \tstruct commit_list *parents = NULL;\n \tconst char *reflog_msg, *author;\n \tstruct strbuf sb = STRBUF_INIT;\n \n+\tif (state->exact) {\n+\t\t/*\n+\t\t * Scan meta file for parents + other data\n+\t\t */\n+\n+\t\tstruct strbuf line = STRBUF_INIT;\n+\t\tFILE *fp = xfopen(am_path(state, \"meta\"), \"r\");\n+\n+\t\twhile (!strbuf_getline_lf(&line, fp)) {\n+\t\t\tconst char *rest;\n+\n+\t\t\tif (skip_prefix(line.buf, \"commit \", &rest)) {\n+\t\t\t\tif (get_oid_hex(rest, &meta_commit))\n+\t\t\t\t\tdie(\"invalid exact metadata (commit)\");\n+\t\t\t} else if (skip_prefix(line.buf, \"tree \", &rest)) {\n+\t\t\t\tif (get_oid_hex(rest, &meta_tree))\n+\t\t\t\t\tdie(\"invalid exact metadata (tree)\");\n+\t\t\t} else if (skip_prefix(line.buf, \"parent \", &rest)) {\n+\t\t\t\tif (get_oid_hex(rest, &parent))\n+\t\t\t\t\tdie(\"invalid exact metadata (parent)\");\n+\n+\t\t\t\tcommit_list_insert(lookup_commit(the_repository, &parent), &parents);\n+\t\t\t} else if (skip_prefix(line.buf, \"author \", &rest)) {\n+\t\t\t\tauthor = strdup(rest);\n+\t\t\t} else if (skip_prefix(line.buf, \"committer \", &rest)) {\n+\t\t\t\tchar *name_copy;\n+\t\t\t\tchar *email;\n+\t\t\t\tchar *email_copy;\n+\t\t\t\tchar *date;\n+\n+\t\t\t\temail = strstr(rest, \" <\");\n+\t\t\t\tif (!email)\n+\t\t\t\t\tdie(\"invalid exact metadata (committer name)\");\n+\n+\t\t\t\tname_copy = xstrndup(rest, email - rest);\n+\t\t\t\temail += 2;\n+\t\t\t\tsetenv(\"GIT_COMMITTER_NAME\", name_copy, 1);\n+\t\t\t\tfree(name_copy);\n+\n+\t\t\t\tdate = strstr(email, \"> \");\n+\t\t\t\tif (!date)\n+\t\t\t\t\tdie(\"invalid exact metadata (committer email)\");\n+\n+\t\t\t\temail_copy = xstrndup(email, date - email);\n+\t\t\t\tdate += 2;\n+\t\t\t\tsetenv(\"GIT_COMMITTER_EMAIL\", email_copy, 1);\n+\t\t\t\tfree(email_copy);\n+\n+\t\t\t\tsetenv(\"GIT_COMMITTER_DATE\", date, 1);\n+\t\t\t} else if (line.len == 0) {\n+\t\t\t\tbreak;\n+\t\t\t} else {\n+\t\t\t\tdie(\"unknown exact metadata: %.*s\", line.len, line.buf);\n+\t\t\t}\n+\t\t}\n+\n+\t\tfclose(fp);\n+\t}\n+\n \tif (run_hook_le(NULL, \"pre-applypatch\", NULL))\n \t\texit(1);\n \n \tif (write_cache_as_tree(&tree, 0, NULL))\n \t\tdie(_(\"git write-tree failed to write a tree\"));\n \n-\tif (!get_oid_commit(\"HEAD\", &parent)) {\n+\tif (state->exact && !oideq(&tree, &meta_tree))\n+\t\tdie(\"tree mismatch\");\n+\n+\tif (state->exact) {\n+\t\t/*\n+\t\t * Already got parents above.\n+\t\t */\n+\t} else if (!get_oid_commit(\"HEAD\", &parent)) {\n \t\told_oid = &parent;\n \t\tcommit_list_insert(lookup_commit(the_repository, &parent),\n \t\t\t\t &parents);\n@@ -1569,19 +1643,28 @@ static void do_commit(const struct am_state *state)\n \t\tsay(state, stderr, _(\"applying to an empty history\"));\n \t}\n \n-\tauthor = fmt_ident(state->author_name, state->author_email,\n-\t\tWANT_AUTHOR_IDENT,\n-\t\t\tstate->ignore_date ? NULL : state->author_date,\n-\t\t\tIDENT_STRICT);\n-\n-\tif (state->committer_date_is_author_date)\n-\t\tsetenv(\"GIT_COMMITTER_DATE\",\n-\t\t\tstate->ignore_date ? \"\" : state->author_date, 1);\n+\tif (state->exact) {\n+\t\t/*\n+\t\t * Already got author above.\n+\t\t */\n+\t} else {\n+\t\tauthor = fmt_ident(state->author_name, state->author_email,\n+\t\t\tWANT_AUTHOR_IDENT,\n+\t\t\t\tstate->ignore_date ? NULL : state->author_date,\n+\t\t\t\tIDENT_STRICT);\n+\n+\t\tif (state->committer_date_is_author_date)\n+\t\t\tsetenv(\"GIT_COMMITTER_DATE\",\n+\t\t\t\tstate->ignore_date ? \"\" : state->author_date, 1);\n+\t}\n \n \tif (commit_tree(state->msg, state->msg_len, &tree, parents, &commit,\n \t\t\tauthor, state->sign_commit))\n \t\tdie(_(\"failed to write commit object\"));\n \n+\tif (state->exact && !oideq(&commit, &meta_commit))\n+\t\tdie(\"sha1 mismatch\");\n+\n \treflog_msg = getenv(\"GIT_REFLOG_ACTION\");\n \tif (!reflog_msg)\n \t\treflog_msg = \"am\";\n@@ -2182,6 +2265,8 @@ int cmd_am(int argc, const char **argv, const char *prefix)\n \t\t\t0, PARSE_OPT_NONEG),\n \t\tOPT_BOOL('c', \"scissors\", &state.scissors,\n \t\t\tN_(\"strip everything before a scissors line\")),\n+\t\tOPT_BOOL('e', \"exact\", &state.exact,\n+\t\t\tN_(\"preserve exact metadata, including sha1\")),\n \t\tOPT_PASSTHRU_ARGV(0, \"whitespace\", &state.git_apply_opts, N_(\"action\"),\n \t\t\tN_(\"pass it through git-apply\"),\n \t\t\t0),\n-- \n2.23.0.718.g3120370db8\n\n"},{"id":"384174","messageId":"20191016111009.GE13154@1wt.eu","threadId":"52044","inReplyTo":"b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Willy Tarreau","fromEmail":"w@1wt.eu","sentAt":"2019-10-16T11:10:09Z","receivedAt":"2019-10-16T11:10:30Z","isPatch":false,"sender":{"key":"w@1wt.eu","avatar":"https://avatars.githubusercontent.com/u/8141789?v=4"},"body":"Hi Vegard,\n\nOn Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:\n> (cross-posted to git, LKML, and the kernel workflows mailing lists.)\n> \n> Hi all,\n> \n> I've been following Konstantin Ryabitsev's quest for better development\n> and communication tools for the kernel [1][2][3], and I would like to\n> propose a relatively straightforward idea which I think could bring a\n> lot to the table.\n> \n> Step 1:\n> \n> * git send-email needs to include parent SHA1s and generally all the\n> information needed to perfectly recreate the commit when applied so\n> that all the SHA1s remain the same\n> \n> * git am (or an alternative command) needs to recreate the commit\n> perfectly when applied, including applying it to the correct parent\n> \n> Having these two will allow a perfect mapping between email and git;\n> essentially email just becomes a transport for git. There are a lot of\n> advantages to this, particularly that you have a stable way to refer to\n> a patch or commit (despite it appearing on a mailing list), and there\n> is no need for \"changeset IDs\" or whatever, since you can just use the\n> git SHA1 which is unique, unambiguous, and stable.\n\nI agree this would be great and have been missing this a number of times,\neventhough I'm aware of git-send-pack/git-receive-pack. The text format\nis way more convenient for a lot of reasons. It could also help with\nGreg's idea of using the commit IDs to reference bugs, as such IDs could\nremain stable within a series before it is merged, and as such referenced\nin subsequent commit messages. It could also be useful to avoid losing\nnotes related to a patch once it's merged.\n\n> Step 3:\n> \n> * Instead of describing a patchset in a separate introduction email, we\n> can create a merge commit between the parent of the first commit in\n> the series and the last and put the patchset description in the merge\n> commit [5]. This means the patchset description also gets to be part\n> of git history.\n> \n> (This would require support for git send-email/am to be able to send\n> and apply merge commits -- at least those which have the same tree as\n> one of the parents. This is _not_ yet supported in my proposed git\n> patches.)\n\nThat's a good idea, as we've all seen long series with a very detailed\ndescription in patch 0 and much less context in subsequent patches, thus\nlosing the context once merged.\n\n> * stable SHA1s means we can refer to previous versions of a patchset by\n> SHA1 rather than archive links. I propose a new changelog tag for\n> this, maybe \"Previous:\" or maybe even a full list of \"v1:\", \"v2:\",\n> etc. with a SHA1 or ref. Note that these SHA1s do *not* need to exist\n> in Linus's repo, but those who want can pull those branches from the\n> bot-maintained repo on git.kernel.org.\n\nFor me this mainly brings the benefit of finally having a unique identifier\nfor multiple iterations of a patchset. It then becomes easier to use this\nidentifier to designate the functional work, regardless of the number of\nupdates it gets. Of course it's never that black and white since such work\nmay itself merge multiple other patchsets but for most use cases it can\nhelp.\n\nWilly\n"},{"id":"384185","messageId":"20191016150020.cr6jgfpd2c6fyg7t@yadavpratyush.com","threadId":"52044","inReplyTo":"b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-10-16T15:00:20Z","receivedAt":"2019-10-16T15:00:31Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"Hi Vegard,\n\nOn 16/10/19 12:22PM, Vegard Nossum wrote:\n> (cross-posted to git, LKML, and the kernel workflows mailing lists.)\n> \n> Hi all,\n> \n> I've been following Konstantin Ryabitsev's quest for better development\n> and communication tools for the kernel [1][2][3], and I would like to\n> propose a relatively straightforward idea which I think could bring a\n> lot to the table.\n> \n> Step 1:\n> \n> * git send-email needs to include parent SHA1s and generally all the\n> information needed to perfectly recreate the commit when applied so\n> that all the SHA1s remain the same\n> \n> * git am (or an alternative command) needs to recreate the commit\n> perfectly when applied, including applying it to the correct parent\n> \n> Having these two will allow a perfect mapping between email and git;\n> essentially email just becomes a transport for git. There are a lot of\n> advantages to this, particularly that you have a stable way to refer to\n> a patch or commit (despite it appearing on a mailing list), and there\n> is no need for \"changeset IDs\" or whatever, since you can just use the\n> git SHA1 which is unique, unambiguous, and stable.\n \nFWIW, I like the idea.\n\n> As a rough proof of concept I've attached 3 git patches which implement\n> this. There are issues to work out like exact format, encodings, mail\n> mangling, error handling, etc., but hopefully the git community can\n> help out here. (Improvement suggestions are welcome!)\n> \n> Step 2:\n> \n> * A bot that follows LKML (and other lists) and imports patchsets into\n> a git repository hosted on git.kernel.org\n> \n> * The bot can add git notes with URLs to lore (and/or other mailing\n> list archives) and store them in e.g. refs/notes/lore,\n> refs/notes/lkml, etc.\n> \n> (For those who don't use git notes yet: they are essentially small\n> bits of information you can add to a commit without changing its SHA1,\n> and you can configure tools like 'git log' to show these at the bottom\n> of a commit. Notes can also exist in a repo completely separate from\n> the commits they attach data to, so there is _zero_ overhead for those\n> who don't want to use this.)\n> \n> * Maintainers can either pull patchsets directly from this bot-\n> maintained repo OR they can continue to apply patches from their inbox\n> (the result should be the same either way) OR they can continue in the\n> old-style process (at least for a while) and just not have the\n> benefits of the new process.\n> \n> Step 3:\n> \n> * Instead of describing a patchset in a separate introduction email, we\n> can create a merge commit between the parent of the first commit in\n> the series and the last and put the patchset description in the merge\n> commit [5]. This means the patchset description also gets to be part\n> of git history.\n> \n> (This would require support for git send-email/am to be able to send\n> and apply merge commits -- at least those which have the same tree as\n> one of the parents. This is _not_ yet supported in my proposed git\n> patches.)\n\nCan sending merge commits via email work with your proposed '--exact'? \nSay I'm the maintainer, and you fork off a feature branch off my master, \nadd a few commits that introduce your new feature, and then merge it \ninto my master, and then send those commits, including the merge.\n\nNow in that scenario, say the tip of your feature branch was X and the \ntip of my 'master' was Y when you sent your patches. Now while your \npatches are still being reviewed, I merge in some other branch creating \na merge commit Z on my master.\n\nNow your merge's first parent was Y and second parent was X. But now the \ntip of my master is Z, so the first parent of your merge needs to be Z, \nnot Y. Changing the first parent would mean a different commit hash.\n\nSo, the way I see it, your proposed merge commits via email can't work \nwith '--exact'. Do I understand this situation correctly? Am I missing \nsomething?\n\nMaybe a better idea would be to allow 'am' to create these merges \nlocally when applying the patches. That would mean having to merge the \nseparate branch along with applying the patches, otherwise the cover \nletter text is lost. This might not be something everyone wants. I for \none don't. When I apply patches via 'am', I first keep them on a \nseparate branch, test them out, and then merge them into 'master'.\n\nSo a yet another alternative could be to save the cover letter as the \nbranch description. This branch description can then be used to generate \nthe merge message. IIRC, Denton Liu is working on generating the cover \nletter text from branch description, so this feature would be like its \ninverse.\n \n> * stable SHA1s means we can refer to previous versions of a patchset by\n> SHA1 rather than archive links. I propose a new changelog tag for\n> this, maybe \"Previous:\" or maybe even a full list of \"v1:\", \"v2:\",\n> etc. with a SHA1 or ref. Note that these SHA1s do *not* need to exist\n> in Linus's repo, but those who want can pull those branches from the\n> bot-maintained repo on git.kernel.org.\n> \n> Advantages:\n> \n> - we can keep using email to post patches/patchsets\n> \n> - the process is opt-in (but should be encouraged) for both authors and\n> maintainers, and the transition can happen over time\n> \n> - there is a central repo for convenience, but it is not necessary for\n> development to happen and is not a single point of failure -- it's\n> more like Linus's repo and can be moved or even replicated from\n> scratch by somebody else simply by having mailing list archives\n> \n> - allows quick lookup of patch/patchset <-> email discussion within git\n> \n> - allows diffing between versions of a single logical patchset\n> \n> - patchset descriptions naturally become part of the changelog that ends\n> up in Linus's tree\n> \n> Disadvantages:\n> \n> - requires patching git\n> \n> - requires a bot to continuously create branches for patchsets sent to\n> mailing lists\n> \n> - increased storage/bandwidth for git.kernel.org (?)\n> \n> - may need a couple of new wrapper scripts to automate patchset\n> construction/versioning\n\nJust to play the devil's advocate, even though I'm in favor of something \nlike this, I'll add in another disadvantage:\n\n- The maintainer can't make small edits before pushing the changes out. \n\nI do that every now and then for git-gui, and Junio does that sometimes \nfor Git. I don't know if the folks over at Linux do something like this, \nbut using '--exact' would mean that contributors would have to send a \nre-roll for even minor changes. Its mostly an inconvenience instead of a \nproblem, but I thought I'd point it out.\n \n> Thoughts?\n\nOne more question, not strictly related to your proposal: right now, \nwhen I apply patches from contributors, I pass '-s' to 'am', so the \napplied commit would have my sign-off. The way I see it, that sign-off \nis supposed to signify that I have the right to push out the commit to \nthe \"main\" repo, just like the author's sign-off means that they have \nthe right to send me that commit.\n\nLooking at git.git, I notice that Junio does the same. The new '--exact' \nwould be incompatible with '-s', correct (since the commit message has \nchanged, the SHA1 would also change)? So firstly, make sure you account \nfor something like that if you haven't already (I haven't found the time \nto read your patches yet). Secondly, is it all right for the maintainer \nto just not sign-off on the commits they push out?\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"384187","messageId":"20191016144517.giwip4yuaxtcd64g@LykOS.localdomain","threadId":"52044","inReplyTo":"20191016111009.GE13154@1wt.eu","subject":"Re: email as a bona fide git transport","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2019-10-16T14:45:19Z","receivedAt":"2019-10-16T15:39:52Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"Hi Willy, Vegard.\n\nOn Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:\n> Hi Vegard,\n> \n> On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:\n> > (cross-posted to git, LKML, and the kernel workflows mailing lists.)\n> > \n> > Hi all,\n> > \n> > I've been following Konstantin Ryabitsev's quest for better development\n> > and communication tools for the kernel [1][2][3], and I would like to\n> > propose a relatively straightforward idea which I think could bring a\n> > lot to the table.\n> > \n> > Step 1:\n> > \n> > * git send-email needs to include parent SHA1s and generally all the\n> > information needed to perfectly recreate the commit when applied so\n> > that all the SHA1s remain the same\n> > \n> > * git am (or an alternative command) needs to recreate the commit\n> > perfectly when applied, including applying it to the correct parent\n> > \n> > Having these two will allow a perfect mapping between email and git;\n> > essentially email just becomes a transport for git. There are a lot of\n> > advantages to this, particularly that you have a stable way to refer to\n> > a patch or commit (despite it appearing on a mailing list), and there\n> > is no need for \"changeset IDs\" or whatever, since you can just use the\n> > git SHA1 which is unique, unambiguous, and stable.\n\nI wonder if it'd be also possible to then embed gpg signatures over\nsend-mail payloads so as they can be transparently transferred to the\ncommit.\n\n-Santiago\n"},{"id":"384214","messageId":"20191016205736.GA259536@google.com","threadId":"52044","inReplyTo":"b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2019-10-16T20:57:36Z","receivedAt":"2019-10-16T20:57:47Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nA few small points.\n\nVegard Nossum wrote:\n\n> * git am (or an alternative command) needs to recreate the commit\n> perfectly when applied, including applying it to the correct parent\n\nInteresting. \"git format-patch\" has a --base option to do some of\nwhat you're looking for, for the sake of snowpatch\n. Though it's not exactly the\nsame thing you mean.\n\nWe also discussed sending merge commits by mail recently in the\nvirtual git committer summit[1].\n\nOf course, the devil is in the details. It's straightforward to use\n\"git bundle\" to use mail as a Git transport today, but presumably you\nalso want the ability to perform reviews along the way and that's not\nso easy with a binary format. Do you have more details on what you'd\nwant the format to look like, particularly for merge commits?\n\n[...]\n> there\n> is no need for \"changeset IDs\" or whatever, since you can just use the\n> git SHA1 which is unique, unambiguous, and stable.\n\nIn [2] the hope was for some identifier that is preserved by \"git\nrebase\" and \"git commit --amend\" (so that you can track the evolution\nof a change as the author improves it in response to reviews). Is\nthat the conversation you're alluding to?\n\n[...]\n> Disadvantages:\n>\n> - requires patching git\n\nThat's not a disadvantage. It means get to work with the Git project,\nwhich is a welcoming bunch of people, working on userspace (seeing how\nthe other half lives), and improving the lives of everyone using Git.\n\n[...]\n> Date: Sat, 5 Oct 2019 16:15:59 +0200\n> Subject: [PATCH 1/3] format-patch: add --complete\n>\n> Include the raw commit data between the changelog and the diffstat.\n\nOh! I had missed this on first reading because it was in an\nattachment.\n\nI have mixed feelings. Can you say a bit more about the advantages\nand disadvantages relative to sending a git bundle? What happens if a\nmail client or a box along the way mangles whitespace in the commit\nmessage?\n\nHappy hacking,\nJonathan\n\n[1] https://public-inbox.org/git/nycvar.QRO.7.76.6.1909261253400.15067@tvgsbejvaqbjf.bet/\n[2] https://lore.kernel.org/ksummit-discuss/CAD=FV=UPjPpUyFTPjF-Ogzj_6LJLE4PTxMhCoCEDmH1LXSSmpQ@mail.gmail.com/\n"},{"id":"384226","messageId":"xmqqeezc83i6.fsf@gitster-ct.c.googlers.com","threadId":"52044","inReplyTo":"b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-10-17T03:17:21Z","receivedAt":"2019-10-17T03:17:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Vegard Nossum writes:\n\n> Step 1:\n>\n> * git send-email needs to include parent SHA1s and generally all the\n> information needed to perfectly recreate the commit when applied so\n> that all the SHA1s remain the same\n>\n> * git am (or an alternative command) needs to recreate the commit\n> perfectly when applied, including applying it to the correct parent\n\nYou can record and convey the commit object name a series is meant\nto be applied on top already, and it in general is a good way to\ngive a wider context in order to explain and justify the series.\n\nOn the other hand, \"all the information needed to recreate...\" is\nnot very useful. If you want the commit object to be exactly what\nyou want to see at the tip of the end result, you are better off\nasking your upstream to pull. Using e-mail for that makes you and\nproject participants give up a lot of benefits the workflow based on\ne-mail gives you, the biggest of which is the ease of giving\nsuggestions for improvements. Once you insist \"perfectly recreate\nthe commit\", you are not willing to take any input from the\nsidelines---worse yet, you are even dictating when the upstream\nruns \"git am\" to turn them into commits, and do so without reading\nthe patches (there is no point reviewing as the person who runs \"git\nam\" is not even allowed to fix typo or make obvious fixes to the\ncode, which will fail to perfectly recreate the commit).\n\nIn short, one should resist temptation to bring up \"perfect\nreproduction\" when one talks about e-mail workflow.\n\n> * Instead of describing a patchset in a separate introduction email, we\n> can create a merge commit between the parent of the first commit in\n> the series and the last and put the patchset description in the merge\n> commit [5]. This means the patchset description also gets to be part\n> of git history.\n\nThis has been done with tools around git-core, and merits a more\nofficial support. When merging a topic, it is a good idea to\nexplain in the merge commit that brings in the topic to the mainline\nwhat the topic is about, and at least in the past few years Linus\nand other maintainers both within and outside the kernel have been\ndoing so. The cover-letter material in [PATCH 00/NN] obviously can\nhelp those integrators when they write the merge message.\n\n> (This would require support for git send-email/am to be able to send\n> and apply merge commits -- at least those which have the same tree as\n> one of the parents. This is _not_ yet supported in my proposed git\n> patches.)\n\nThis does not require much from format-patch and am. All you need\nto do is to ensure that they can handle an empty commit. What you\nneed more is a support in merge. The outline for the workflow would\ngo like this:\n\n * The contributor prepares an N patch series 1/N..N/N on a single\n topic branch.\n\n * The summary of the series, the message that is meant to help the\n integrator, is recorded as (N+1)th commit at the tip of the topic\n branch, as an empty commit (i.e. a commit that records the same\n tree as its parent).\n\n * \"git format-patch\" is taught, when told to prepare the patch\n e-mails from such a topic branch, to notice the unusual \"an empty\n commit at the tip\" layout, and turn that into 0/N of the message.\n\n * \"git am\" is taught a new option to cap a topic branch made from\n patches 1/N..N/N from the incoming mbox with an extra empty\n commit, whose message is taken from the 0/N cover-letter\n material, to recreate what the contributor had in the second step\n above.\n\n * \"git merge\" is taught, when told to merge a topic branch, to\n notice the unusual \"an empty commit at the tip\" layout, and\n\n (1) merge topic~1 instead to excise the empty commit itself,\n\n (2) take the log message from the empty commit at the tip and use\n it to help prepare the log message of the merge.\n\n"},{"id":"384253","messageId":"a1c33600-14e6-be37-c026-8d8b8e4bad92@oracle.com","threadId":"52044","inReplyTo":"20191016150020.cr6jgfpd2c6fyg7t@yadavpratyush.com","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-17T12:23:58Z","receivedAt":"2019-10-17T12:24:20Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"\nOn 10/16/19 5:00 PM, Pratyush Yadav wrote:\n> On 16/10/19 12:22PM, Vegard Nossum wrote:\n> Just to play the devil's advocate, even though I'm in favor of something\n> like this, I'll add in another disadvantage:\n> \n> - The maintainer can't make small edits before pushing the changes out.\n> \n> I do that every now and then for git-gui, and Junio does that sometimes\n> for Git. I don't know if the folks over at Linux do something like this,\n> but using '--exact' would mean that contributors would have to send a\n> re-roll for even minor changes. Its mostly an inconvenience instead of a\n> problem, but I thought I'd point it out.\n\nI don't think this is a problem.\n\nThe point of 'git am --exact' is not for maintainers per se (although\nthey should use it if they don't have any manual changes to make), but\nfor the bot that keeps track of patchsets submitted via email.\n\nThe important part is that there is a git reference to the patchset that\nwas submitted in the patchset that was merged. You could see it as the\nmaintainer rolling a new version of the patchset locally and merging\nthat instead of merging what was submitted directly.\n\nOf course, this relies strongly on actually having (correct) sha1\nreferences to previous versions inside the changelog. In my original\nidea, this reference would only appear inside the merge commit that\nbinds the patchset together to minimise churn, although maybe it is\nfeasible to also append it to each patch -- in that case, the \"patchset\"\ncommand from my first email is not sufficient to create a new version of\na patchset.\n\n> One more question, not strictly related to your proposal: right now,\n> when I apply patches from contributors, I pass '-s' to 'am', so the\n> applied commit would have my sign-off. The way I see it, that sign-off\n> is supposed to signify that I have the right to push out the commit to\n> the \"main\" repo, just like the author's sign-off means that they have\n> the right to send me that commit.\n> \n> Looking at git.git, I notice that Junio does the same. The new '--exact'\n> would be incompatible with '-s', correct (since the commit message has\n> changed, the SHA1 would also change)? So firstly, make sure you account\n> for something like that if you haven't already (I haven't found the time\n> to read your patches yet). Secondly, is it all right for the maintainer\n> to just not sign-off on the commits they push out?\n\nIn the Linux kernel at least, only the front-line maintainers add their\nsignoffs; higher-level maintainers take pull requests and don't add\ntheir own sign-offs. Only Linus (and Greg, perhaps) has commit rights to\nthe main repository, but he only signs off on the patches that he either\nwrites himself or applies directly from email.\n\nIn any case, I don't think this is a concern because of what I wrote\nabove -- somebody who wants to add their signoff can do it by\nessentially rolling a new version of the patchset that has the signoff,\nbut refers to the sha1 that was submitted to them by the patchset author\nso that you can still find the original commits (without the signoffs)\nand reviews/discussions.\n\nI don't want to create extra work for maintainers, so I think any\nsolution should involve having the existing git tools/workflows do the\nright thing automatically.\n\nHow about this? If 'git am' or 'git am -s' (without --exact) finds an\nemail patch where the exact commit metadata is present, it automatically\nappends a line to the changelog saying where it was taken from:\n\n Submitted-as: 111122223333444455556666777788889999aaaa\n\nor\n\n Applied-from: 111122223333444455556666777788889999aaaa\n\nAlthough, again, this would modify the changelog of the patch itself\nrather than just the changelog of the merge commit... Maybe this is\nenough and we can have the \"patchset\" command also add references to\nprevious versions of each patch rather than the patchset as a whole.\n\n\nVegard\n"},{"id":"384258","messageId":"fec5f11b-8dd4-8450-863f-487960b9dd1c@oracle.com","threadId":"52044","inReplyTo":"20191016205736.GA259536@google.com","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-17T13:08:15Z","receivedAt":"2019-10-17T13:08:33Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"On 10/16/19 10:57 PM, Jonathan Nieder wrote:\n> Hi,\n> \n> A few small points.\n> \n> Vegard Nossum wrote:\n> \n>> * git am (or an alternative command) needs to recreate the commit\n>> perfectly when applied, including applying it to the correct parent\n> \n> Interesting. \"git format-patch\" has a --base option to do some of\n> what you're looking for, for the sake of snowpatch\n> . Though it's not exactly the\n> same thing you mean.\n\nYes, --base is great for importing email patches into git, but does not\nallow resulting commits to have the same sha1 (because it doesn't have\nthe complete author/committer information, mainly), so it doesn't do\nenough for what I want with this proposal.\n\n> We also discussed sending merge commits by mail recently in the\n> virtual git committer summit[1].\n> \n> Of course, the devil is in the details. It's straightforward to use\n> \"git bundle\" to use mail as a Git transport today, but presumably you\n> also want the ability to perform reviews along the way and that's not\n> so easy with a binary format. Do you have more details on what you'd\n> want the format to look like, particularly for merge commits?\n\nYes, one of the goals is to continue to use git-send-email and be able\nto view and review patches on a mailing list with minimal intrusion to\nexisting processes.\n\nI did not envision supporting merge commits where the resulting tree is\ndifferent from all of its parents, which means any merge commits run\nthrough 'git-format-patch --complete' would just have multiple \"parent\"\nlines and no diff where the diff would normally be.\n\n>> is no need for \"changeset IDs\" or whatever, since you can just use the\n>> git SHA1 which is unique, unambiguous, and stable.\n> \n> In [2] the hope was for some identifier that is preserved by \"git\n> rebase\" and \"git commit --amend\" (so that you can track the evolution\n> of a change as the author improves it in response to reviews). Is\n> that the conversation you're alluding to?\n\nYes.\n\n(Not the specific email/thread you linked, but yes, this is the general\nconversation about having stable identifiers I'm referring to.)\n\n> \n> [...]\n>> Disadvantages:\n>>\n>> - requires patching git\n> \n> That's not a disadvantage. It means get to work with the Git project,\n> which is a welcoming bunch of people, working on userspace (seeing how\n> the other half lives), and improving the lives of everyone using Git.\n\nTrue! :-)\n\n>> Date: Sat, 5 Oct 2019 16:15:59 +0200\n>> Subject: [PATCH 1/3] format-patch: add --complete\n>>\n>> Include the raw commit data between the changelog and the diffstat.\n> \n> Oh! I had missed this on first reading because it was in an\n> attachment.\n> \n> I have mixed feelings. Can you say a bit more about the advantages\n> and disadvantages relative to sending a git bundle? What happens if a\n> mail client or a box along the way mangles whitespace in the commit\n> message?\n\nYes, as we both said above: git bundle is not human readable and does\nnot lend itself to reviews in mail clients or on mailing lists.\n\nAny kind of mangling is a serious concern, and my thoughts are:\n\n - The _diff_ itself should already be safe from mangling. If this were\nnot the case, then sending patches by email would be completely unsafe\nand would need to be fixed somehow anyway.\n\n - I think I remember seeing something in either 'git am' or 'git\nmailinfo' about format=flowed apparently allowing whitespace to\ndisappear from the line endings.\n\n - Isolated problems like that could be preemptively fixed (or at least\nwarned about) on the submitter side by e.g. warning about potential\nissues when committing or running format-patch/send-email)\n\n - If some mail software is susceptible to mangling patches, then I\nthink it would great to have a mechanism for detecting that -- which\n\"git-format-patch --complete\" would be! :-)\n\n - It is true that the commit message itself (and perhaps particularly\npeople's names) is especially vulnerable to mangling and/or reencoding\n(I noticed that 'git am' seems to convert to utf8 before committing). I\nhonestly don't know if this would be a problem in practice, as I don't\nknow too much about mail software and encodings. If most people use\nformat-patch/send-email to send patches, then maybe it's not actually a\nproblem because everything is either kept as utf-8 to start with or\nencoded/decoded consistently across the git userbase?\n\n - I was thinking of hex-encoding the raw bytes of the author and\ncommitter lines of the extra commit metadata in the final email to keep\neverything as ASCII and avoid character set conversions. It is true that\nthis does not stop mangling of the changelog...\n\n - I suspect that if mangling was a problem in practice, then we would\nhave seen it already and the solution to it is not specific to what I'm\nproposing here.\n\nI'd love for somebody who is more knowledgeable about email and encoding\nto chime in here. It is definitely one of the biggest potential problems\nand it would be good to approach it in a way that doesn't require lots\nof red tape after it has already been implemented.\n\n\nVegard\n\n> \n> Happy hacking,\n> Jonathan\n> \n> [1] https://public-inbox.org/git/nycvar.QRO.7.76.6.1909261253400.15067@tvgsbejvaqbjf.bet/\n> [2] https://lore.kernel.org/ksummit-discuss/CAD=FV=UPjPpUyFTPjF-Ogzj_6LJLE4PTxMhCoCEDmH1LXSSmpQ@mail.gmail.com/\n> \n"},{"id":"384259","messageId":"20191017131140.GG25548@mit.edu","threadId":"52044","inReplyTo":"a1c33600-14e6-be37-c026-8d8b8e4bad92@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2019-10-17T13:11:40Z","receivedAt":"2019-10-17T13:12:00Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Oct 17, 2019 at 02:23:58PM +0200, Vegard Nossum wrote:\n> Of course, this relies strongly on actually having (correct) sha1\n> references to previous versions inside the changelog. In my original\n> idea, this reference would only appear inside the merge commit that\n> binds the patchset together to minimise churn, although maybe it is\n> feasible to also append it to each patch -- in that case, the \"patchset\"\n> command from my first email is not sufficient to create a new version of\n> a patchset.\n\nThis also relies on the base of the commit actually being a public\nSHA1. Sometimes developers will cherry-pick in a patch that they need\nso that the kernel will actually *boot* (or otherwise fix problems\nthat have been fixed in other subsystems, but not yet landed in -rc2\nor -rc3).\n\nOf course, we could tell people that they should always create their\npatches off of the last stable version (but then there may have been\nchanges pulled in via the last merge window that makes their patch not\napply), or they could be told to develop against -rc2 or -rc3, and\nthen cherry pick the required fix-up patches on top of -rc2 and -rc3,\nbut then they have to do a lot more rebuilding.\n\nSo there are no perfect solutions here, and while in the ideal world,\n-rc2 and -rc3 should be perfectly stable enough for developers so that\nthey never need to manually patch in stablization patches, we need to\nlive in the real world. I believe that Darrick told me that in the\nprevious development cycle, he had to wait until -rc4 before the tree\nwas stable enough for him to start building xfs patches on top\nmainline.\n\n(This is also true for this development cycle if you enable\nCONFIG_KMEMLEAK, although fortunately, the workaround that worked for\nme was to just CONFIG_KMEMLEAK --- although of course, if I do have to\nrun a KMEMLEAK test run, I'll need to cherry-pick the fix which landed\nthis week on top of the ext4 git tree.)\n\nWhat this all might mean is that sometimes it will make sense to allow\nthe user to override the base commit so such stablization patches can\nbe elided. Of course, we could force the user to create a separate\nbranch and rebase, but can be quite painful and slow --- and they\nwon't be able to test the rebased branch anyway, unless we then want\nto tell them to cherry pick the stablization patches on top, and then\nremove them before running \"git send-email\".\n\n\t\t\t\t\t\t- Ted\n"},{"id":"384260","messageId":"9ec63ec0-c322-610c-e1b8-b673b983dc74@oracle.com","threadId":"52044","inReplyTo":"xmqqeezc83i6.fsf@gitster-ct.c.googlers.com","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-17T13:30:54Z","receivedAt":"2019-10-17T13:33:15Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"On 10/17/19 5:17 AM, Junio C Hamano wrote:\n> Vegard Nossum writes:\n> \n>> Step 1:\n>>\n>> * git send-email needs to include parent SHA1s and generally all the\n>> information needed to perfectly recreate the commit when applied so\n>> that all the SHA1s remain the same\n>>\n>> * git am (or an alternative command) needs to recreate the commit\n>> perfectly when applied, including applying it to the correct parent\n> \n> You can record and convey the commit object name a series is meant\n> to be applied on top already, and it in general is a good way to\n> give a wider context in order to explain and justify the series.\n> \n> On the other hand, \"all the information needed to recreate...\" is\n> not very useful. If you want the commit object to be exactly what\n> you want to see at the tip of the end result, you are better off\n> asking your upstream to pull. Using e-mail for that makes you and\n> project participants give up a lot of benefits the workflow based on\n> e-mail gives you, the biggest of which is the ease of giving\n> suggestions for improvements. Once you insist \"perfectly recreate\n> the commit\", you are not willing to take any input from the\n> sidelines---worse yet, you are even dictating when the upstream\n> runs \"git am\" to turn them into commits, and do so without reading\n> the patches (there is no point reviewing as the person who runs \"git\n> am\" is not even allowed to fix typo or make obvious fixes to the\n> code, which will fail to perfectly recreate the commit).\n> \n> In short, one should resist temptation to bring up \"perfect\n> reproduction\" when one talks about e-mail workflow.\n\nPlease see what I wrote to Pratyush Yadav here:\n\nhttps://public-inbox.org/git/a1c33600-14e6-be37-c026-8d8b8e4bad92@oracle.com/\n\nTL;DR: the goal is not necessarily for maintainers to be able to merge\nthe patchset with the same SHA1 that the submitter had, but for the\npatchset to have a definite SHA1 that lives in git, and which can be\nused by all the participants -- submitter, reviewers, bots (including\npotentially testing/CI infrastructure), and maintainers.\n\nI am definitely not proposing to get rid of the email workflow -- on the\ncontrary, this it the workflow I want to preserve! :-) The \"workflows\"\nmailing list was created for the purpose of discussing this topic (in\nthe context of Linux kernel development) and right now there are many\nproposals that either completely cut out email or reduce it to something\nlike pull requests. My proposal keeps almost everything the same, except\nfor a few lines of extra metadata before the actual diff.\n\n(I will answer the rest of your email separately.)\n\n\nVegard\n"},{"id":"384262","messageId":"507d7293-964a-048b-2de6-98e7e7982cfb@oracle.com","threadId":"52044","inReplyTo":"20191017131140.GG25548@mit.edu","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-17T14:01:33Z","receivedAt":"2019-10-17T14:01:53Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"\nOn 10/17/19 3:11 PM, Theodore Y. Ts'o wrote:\n> On Thu, Oct 17, 2019 at 02:23:58PM +0200, Vegard Nossum wrote:\n>> Of course, this relies strongly on actually having (correct) sha1\n>> references to previous versions inside the changelog. In my original\n>> idea, this reference would only appear inside the merge commit that\n>> binds the patchset together to minimise churn, although maybe it is\n>> feasible to also append it to each patch -- in that case, the \"patchset\"\n>> command from my first email is not sufficient to create a new version of\n>> a patchset.\n> \n> This also relies on the base of the commit actually being a public\n> SHA1. Sometimes developers will cherry-pick in a patch that they need\n> so that the kernel will actually *boot* (or otherwise fix problems\n> that have been fixed in other subsystems, but not yet landed in -rc2\n> or -rc3).\n> \n> Of course, we could tell people that they should always create their\n> patches off of the last stable version (but then there may have been\n> changes pulled in via the last merge window that makes their patch not\n> apply), or they could be told to develop against -rc2 or -rc3, and\n> then cherry pick the required fix-up patches on top of -rc2 and -rc3,\n> but then they have to do a lot more rebuilding.\n> \n> So there are no perfect solutions here, and while in the ideal world,\n> -rc2 and -rc3 should be perfectly stable enough for developers so that\n> they never need to manually patch in stablization patches, we need to\n> live in the real world. I believe that Darrick told me that in the\n> previous development cycle, he had to wait until -rc4 before the tree\n> was stable enough for him to start building xfs patches on top\n> mainline.\n> \n> (This is also true for this development cycle if you enable\n> CONFIG_KMEMLEAK, although fortunately, the workaround that worked for\n> me was to just CONFIG_KMEMLEAK --- although of course, if I do have to\n> run a KMEMLEAK test run, I'll need to cherry-pick the fix which landed\n> this week on top of the ext4 git tree.)\n> \n> What this all might mean is that sometimes it will make sense to allow\n> the user to override the base commit so such stablization patches can\n> be elided. Of course, we could force the user to create a separate\n> branch and rebase, but can be quite painful and slow --- and they\n> won't be able to test the rebased branch anyway, unless we then want\n> to tell them to cherry pick the stablization patches on top, and then\n> remove them before running \"git send-email\".\n\nGood points.\n\nI suspect that you should almost always be able to find a good base\nrevision to build and test your changes on.\n\nIn your example, couldn't Darrick simply base his xfs work on the latest\nxfs branch that was pulled by Linus? That should be up to date with all\nthings xfs without having any of the things that made Linus's tree not\nwork for him.\n\nOtherwise, you could apply the stabilisation patches and then do your\nfinal testing in a branch that merges that with your patchset, like so:\n\n rc1 o -----> fixup A ------> fixup B ---->o merge (tested)\n(base) \\ /\n \\ /\n ---> patch 001 --> patch 002 -->o patchset (submitted)\n\nIt does not seem too hard to me, and it should be pretty safe from a\ntest-what-you-ship point of view assuming the fixups and your patches\nreally are independent.\n\nI think the more difficult problem to solve might be how to ensure that\nthe base commit is actually public/reachable when this is the intention.\nA bot watching the mailing list could always respond with a \"Hey, I\ndon't have that, could you rebase the series or push it somewhere?\". But\nit would be even better if git could tell you when you're about to\nsubmit a patch. Maybe something like:\n\n git send-email --ensure-reachable-from [remote] rev^^..\n\nIn the worst case, I guess the base commit will just not be available --\nthe email will still have a sha1 on it, though, and which might still be\nusable as an identifier for the patch/patchset. If not, it's still not\nworse than the current workflow (which would still work).\n\n\nVegard\n"},{"id":"384265","messageId":"20191017144708.GI25548@mit.edu","threadId":"52044","inReplyTo":"507d7293-964a-048b-2de6-98e7e7982cfb@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2019-10-17T14:47:08Z","receivedAt":"2019-10-17T14:47:24Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Oct 17, 2019 at 04:01:33PM +0200, Vegard Nossum wrote:\n> \n> In your example, couldn't Darrick simply base his xfs work on the latest\n> xfs branch that was pulled by Linus? That should be up to date with all\n> things xfs without having any of the things that made Linus's tree not\n> work for him.\n\nSure, but sometimes there are changes in subsystems which the file\nsystem depends upon that were also merged by Linus. So for example,\nthe ext4 branch might be based on v5.3-rc4, and gets pulled after v5.3\nis released, along with a huge number of other subsystem trees, so the\ndelta between v5.3 and v5.3-rc1 is ***huge***.\n\nSo while I could base my development on my previous ext4.git branch\n(based off of v5.3-rc4), at *some* point I need to be able to sync up\nwith upstream. And the usual way to do this is to start a new\ndevelopment branch based on (for example) v5.4-rc2, or in some cases\nv5.4-rc4.\n\nWe could keep the development branch on based off of v5.3-rc4, and\nwait until things stablize, and *then* merge in v5.4-rcX, when\nv5.4-rcX is finally stable, but that makes for a more complex merge,\nand so it means that things like \"git log origin..master\" don't really\nwork any more. So the preferred development practice is very much....\n\n rc2 o --> patch 1 --> patch 2 --> ... --> patch N \n(origin) (master)\n\nWhere the \"master\" branch gets merged into the rewinding \"dev\" branch\n(which works much like git's pu branch), and where the \"master\" branch\nis what Linus will merge at the next merge window.\n\n> Otherwise, you could apply the stabilisation patches and then do your\n> final testing in a branch that merges that with your patchset, like so:\n> \n> rc1 o -----> fixup A ------> fixup B ---->o merge (tested)\n> (base) \\ /\n> \\ /\n> ---> patch 001 --> patch 002 -->o patchset (submitted)\n\nI cloud do that, but remember that the checked out kernel tree is\nabout a gigabyte (this assumes using git clone --shared, so it doesn't\ninclude the git pack files, and this is source only; the object files\nare another 2.6 GB). I could keep separate checked out trees, and\nseparate build trees, but that burns a lot of disk/SSD space. Or I\ncould switch back and forth by using \"git checkout\" between the\ndevelopment branch and the branch with the stablization patches, but\nthen I'm constantly having to rebuild the object files, and ccache\nonly helps so much.\n\nSo it's much simpler to put the fixup patches at the on top of the\norigin, and then mail them out without having to play git branch\nrebasing gymnastics. When the patch series is finally ready to roll,\nthen the maintainer will apply the patch series on a clean branch,\nsince hopefully by then -rc3 or -rc4 is finally stable enough to use\nas an origin point.\n\nSo the idea is that developer might be sending out revisions of their\npatches on top of -rc1 plus fixup patches, but then the final version\nof the patch series, after a few rounds of review, gets applied on top\nof -rc3 or -rc4.\n\n> I think the more difficult problem to solve might be how to ensure that\n> the base commit is actually public/reachable when this is the intention.\n> A bot watching the mailing list could always respond with a \"Hey, I\n> don't have that, could you rebase the series or push it somewhere?\". But\n> it would be even better if git could tell you when you're about to\n> submit a patch. Maybe something like:\n> \n> git send-email --ensure-reachable-from [remote] rev^^..\n> \n> In the worst case, I guess the base commit will just not be available --\n> the email will still have a sha1 on it, though, and which might still be\n> usable as an identifier for the patch/patchset. If not, it's still not\n> worse than the current workflow (which would still work).\n\n... or what we can do is allow the developer to specify the intended\nbase --- e.g., -rc1, even though his patchset was against \"-rc1 plus fixups\".\n\n\t \t \t \t \t - Ted\n"},{"id":"384266","messageId":"20191017111101.1456faaf@gandalf.local.home","threadId":"52044","inReplyTo":"507d7293-964a-048b-2de6-98e7e7982cfb@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2019-10-17T15:11:01Z","receivedAt":"2019-10-17T15:11:12Z","isPatch":false,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"On Thu, 17 Oct 2019 16:01:33 +0200\nVegard Nossum wrote:\n\n> In your example, couldn't Darrick simply base his xfs work on the latest\n> xfs branch that was pulled by Linus? That should be up to date with all\n> things xfs without having any of the things that made Linus's tree not\n> work for him.\n\nSure, but why?\n\nI thought this whole exercise is to make the process easier. This seems\nto be making it more complex. Now we are going to be demanding\nsubmitters to be basing their work on a specific (older) commit.\n\nI always tell people that submit to me, to base off of one of Linus's\nlatest tags. That's what I do.\n\n-- Steve\n"},{"id":"384295","messageId":"20191017204343.GA1132188@kroah.com","threadId":"52044","inReplyTo":"20191016144517.giwip4yuaxtcd64g@LykOS.localdomain","subject":"Re: email as a bona fide git transport","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2019-10-17T20:43:43Z","receivedAt":"2019-10-17T20:43:55Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Wed, Oct 16, 2019 at 10:45:19AM -0400, Santiago Torres Arias wrote:\n> Hi Willy, Vegard.\n> \n> On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:\n> > Hi Vegard,\n> > \n> > On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:\n> > > (cross-posted to git, LKML, and the kernel workflows mailing lists.)\n> > > \n> > > Hi all,\n> > > \n> > > I've been following Konstantin Ryabitsev's quest for better development\n> > > and communication tools for the kernel [1][2][3], and I would like to\n> > > propose a relatively straightforward idea which I think could bring a\n> > > lot to the table.\n> > > \n> > > Step 1:\n> > > \n> > > * git send-email needs to include parent SHA1s and generally all the\n> > > information needed to perfectly recreate the commit when applied so\n> > > that all the SHA1s remain the same\n> > > \n> > > * git am (or an alternative command) needs to recreate the commit\n> > > perfectly when applied, including applying it to the correct parent\n> > > \n> > > Having these two will allow a perfect mapping between email and git;\n> > > essentially email just becomes a transport for git. There are a lot of\n> > > advantages to this, particularly that you have a stable way to refer to\n> > > a patch or commit (despite it appearing on a mailing list), and there\n> > > is no need for \"changeset IDs\" or whatever, since you can just use the\n> > > git SHA1 which is unique, unambiguous, and stable.\n> \n> I wonder if it'd be also possible to then embed gpg signatures over\n> send-mail payloads so as they can be transparently transferred to the\n> commit.\n\nThat's a crazy idea. It would be nice if we could do that, I like it :)\n\ngreg k-h\n"},{"id":"384296","messageId":"20191017204532.GA6446@chatter.i7.local","threadId":"52044","inReplyTo":"20191017204343.GA1132188@kroah.com","subject":"Re: email as a bona fide git transport","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2019-10-17T20:45:32Z","receivedAt":"2019-10-17T20:45:40Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:\n>> I wonder if it'd be also possible to then embed gpg signatures over\n>> send-mail payloads so as they can be transparently transferred to the\n>> commit.\n>\n>That's a crazy idea. It would be nice if we could do that, I like it \n>:)\n\nIt could only possibly work if nobody ever adds their own \n\"Signed-Off-By\" or any other bylines. I expect this is a deal-breaker \nfor most maintainers.\n\n-K\n"},{"id":"384333","messageId":"20191018013029.GA1167832@kroah.com","threadId":"52044","inReplyTo":"20191017204532.GA6446@chatter.i7.local","subject":"Re: email as a bona fide git transport","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2019-10-18T01:30:29Z","receivedAt":"2019-10-18T01:30:36Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Thu, Oct 17, 2019 at 04:45:32PM -0400, Konstantin Ryabitsev wrote:\n> On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:\n> > > I wonder if it'd be also possible to then embed gpg signatures over\n> > > send-mail payloads so as they can be transparently transferred to the\n> > > commit.\n> > \n> > That's a crazy idea. It would be nice if we could do that, I like it :)\n> \n> It could only possibly work if nobody ever adds their own \"Signed-Off-By\" or\n> any other bylines. I expect this is a deal-breaker for most maintainers.\n\nYeah it is :(\n\nBut, if we could just have the signature on the code change, not the\nchangelog text, that would help with that issue.\n\nthanks,\n\nrgeg k-h\n"},{"id":"384336","messageId":"20191018015447.GB6446@chatter.i7.local","threadId":"52044","inReplyTo":"20191018013029.GA1167832@kroah.com","subject":"Re: email as a bona fide git transport","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2019-10-18T01:54:47Z","receivedAt":"2019-10-18T01:54:54Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:\n>> It could only possibly work if nobody ever adds their own \n>> \"Signed-Off-By\" or\n>> any other bylines. I expect this is a deal-breaker for most maintainers.\n>\n>Yeah it is :(\n>\n>But, if we could just have the signature on the code change, not the\n>changelog text, that would help with that issue.\n\nWe totally should, and I even mused on how we would do that here:\nhttps://public-inbox.org/git/20190910121324.GA6867@pure.paranoia.local/\n\nHowever, since git's PGP signatures are made for the content in the \nactual commit record (tree hash, parent, author, commit message, etc), \nthe only way we could preserve them between the email and the git tree \nis if we never modify any of that data. The SOB and other trailers would \nhave to only be applied to the merge commit, or migrate into commit \nnotes.\n\n-K\n"},{"id":"384343","messageId":"20191018025215.GA15777@1wt.eu","threadId":"52044","inReplyTo":"20191018015447.GB6446@chatter.i7.local","subject":"Re: email as a bona fide git transport","fromName":"Willy Tarreau","fromEmail":"w@1wt.eu","sentAt":"2019-10-18T02:52:16Z","receivedAt":"2019-10-18T04:57:30Z","isPatch":false,"sender":{"key":"w@1wt.eu","avatar":"https://avatars.githubusercontent.com/u/8141789?v=4"},"body":"On Thu, Oct 17, 2019 at 09:54:47PM -0400, Konstantin Ryabitsev wrote:\n> On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:\n> > > It could only possibly work if nobody ever adds their own\n> > > \"Signed-Off-By\" or\n> > > any other bylines. I expect this is a deal-breaker for most maintainers.\n> > \n> > Yeah it is :(\n> > \n> > But, if we could just have the signature on the code change, not the\n> > changelog text, that would help with that issue.\n> \n> We totally should, and I even mused on how we would do that here:\n> https://public-inbox.org/git/20190910121324.GA6867@pure.paranoia.local/\n> \n> However, since git's PGP signatures are made for the content in the actual\n> commit record (tree hash, parent, author, commit message, etc), the only way\n> we could preserve them between the email and the git tree is if we never\n> modify any of that data. The SOB and other trailers would have to only be\n> applied to the merge commit, or migrate into commit notes.\n\nThere's also the possibility to handle this a bit like we do when adding\ncomments before the SOB: a PGP signature would apply to the text *before*\nit only. We could then have long chains of SOB, PGP, SOB, PGP etc.\n\nWilly\n"},{"id":"384363","messageId":"20191018022253.GA29290@dcvr","threadId":"52044","inReplyTo":"b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2019-10-18T02:22:53Z","receivedAt":"2019-10-18T06:02:46Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Vegard Nossum wrote:\n\n\n> Disadvantages:\n> \n> - requires patching git\n\nThe bigger disadvantage is this won't work with a historical\npatch series (and some folks stay on ancient git). But maybe\nthat window for that is only a few years...\n\nThe toughest part right now for public-inbox is trying to make\nsense of --range-diff (supporting --interdiff would be easy, I\nthink...). Also, we've only had --range-diff for a year or\nso.\n\nYour proposal would make things 100% easier for public-inbox\nto deal with future --range-diff uses, however :)\n\n> - requires a bot to continuously create branches for patchsets sent to\n> mailing lists\n\nNot necessarily, being able to search on commit OIDs would\nbe pretty handy itself for dealing with --range-diff output\nin public-inbox, so there's no real need to actually make\nthe branch in git.\n\nI also have a parallel solution in the works to make\n--range-diff output more amenable for search engines like\npublic-inbox by adding blob OIDs to its output:\n\n https://public-inbox.org/git/20191017121045.GA15364@dcvr/\n I shall call myself an \"SEO expert\" from now on :>\n\n> Thoughts?\n\nPretty much the same concerns others brought up around exactness\nand working on top of cherry-picks.\n\n> PS: Eric Wong described something that comes quite close to this idea, but\n> AFAICT without actually recreating commits exactly. I've included the link\n> for completeness. [4]\n\n> [4]: https://lore.kernel.org/workflows/20191008003931.y4rc2dp64gbhv5ju@dcvr/\n\nMy plan is to work on interdiff support in the next week or so\nonce bugs are fixed and public-inbox v1.2 is out the door. Not\nsure about range-diff and reverse-mapping blobs -> trees ->\ncommits, but searching on \"git patch-id --stable\" output is also\non the table.\n\nPS: Attached patches: I have nothing against using MIME for those,\n (not speaking for anybody else). public-inbox needs to handle\n those better w.r.t search indexing linkification. And then\n I found some bugs for --reindex corner cases which I'm still\n working on :x\n"},{"id":"384366","messageId":"4ea21178-0cac-e958-7c69-ad5b4a74e6b5@gandi.net","threadId":"52044","inReplyTo":"20191018025215.GA15777@1wt.eu","subject":"Re: email as a bona fide git transport","fromName":"Nicolas Belouin","fromEmail":"nicolas.belouin@gandi.net","sentAt":"2019-10-18T06:34:17Z","receivedAt":"2019-10-18T06:43:53Z","isPatch":false,"sender":{"key":"nicolas.belouin@gandi.net","avatar":null},"body":"On 10/18/19 4:52 AM, Willy Tarreau wrote:\n> On Thu, Oct 17, 2019 at 09:54:47PM -0400, Konstantin Ryabitsev wrote:\n>> On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:\n>>>> It could only possibly work if nobody ever adds their own\n>>>> \"Signed-Off-By\" or\n>>>> any other bylines. I expect this is a deal-breaker for most maintainers.\n>>> Yeah it is :(\n>>>\n>>> But, if we could just have the signature on the code change, not the\n>>> changelog text, that would help with that issue.\n>> We totally should, and I even mused on how we would do that here:\n>> https://public-inbox.org/git/20190910121324.GA6867@pure.paranoia.local/\n>>\n>> However, since git's PGP signatures are made for the content in the actual\n>> commit record (tree hash, parent, author, commit message, etc), the only way\n>> we could preserve them between the email and the git tree is if we never\n>> modify any of that data. The SOB and other trailers would have to only be\n>> applied to the merge commit, or migrate into commit notes.\n> There's also the possibility to handle this a bit like we do when adding\n> comments before the SOB: a PGP signature would apply to the text *before*\n> it only. We could then have long chains of SOB, PGP, SOB, PGP etc.\n>\n> Willy\n\nI don't think it can work that easily as the signed content is not just\nthe message.\nIt would need git to support nesting signatures and to allow amending a\ncommit without\ntouching the signature and to allow adding one to cover the new content\nand to have a\nway to verify every step.\nMoreover you won't be able to reparent the commit as a maintainer (wich\nI think is\nalso a deal-breaker)\n\nNicolas\n\n"},{"id":"384381","messageId":"56664222-6c29-09dc-ef78-7b380b113c4a@oracle.com","threadId":"52044","inReplyTo":"20191016144517.giwip4yuaxtcd64g@LykOS.localdomain","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-18T14:27:48Z","receivedAt":"2019-10-18T14:28:38Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"\nOn 10/16/19 4:45 PM, Santiago Torres Arias wrote:\n> Hi Willy, Vegard.\n> \n> On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:\n>> Hi Vegard,\n>>\n>> On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:\n>>> (cross-posted to git, LKML, and the kernel workflows mailing lists.)\n>>>\n>>> Hi all,\n>>>\n>>> I've been following Konstantin Ryabitsev's quest for better development\n>>> and communication tools for the kernel [1][2][3], and I would like to\n>>> propose a relatively straightforward idea which I think could bring a\n>>> lot to the table.\n>>>\n>>> Step 1:\n>>>\n>>> * git send-email needs to include parent SHA1s and generally all the\n>>> information needed to perfectly recreate the commit when applied so\n>>> that all the SHA1s remain the same\n>>>\n>>> * git am (or an alternative command) needs to recreate the commit\n>>> perfectly when applied, including applying it to the correct parent\n>>>\n>>> Having these two will allow a perfect mapping between email and git;\n>>> essentially email just becomes a transport for git. There are a lot of\n>>> advantages to this, particularly that you have a stable way to refer to\n>>> a patch or commit (despite it appearing on a mailing list), and there\n>>> is no need for \"changeset IDs\" or whatever, since you can just use the\n>>> git SHA1 which is unique, unambiguous, and stable.\n> \n> I wonder if it'd be also possible to then embed gpg signatures over\n> send-mail payloads so as they can be transparently transferred to the\n> commit.\n> \n> -Santiago\n> \n\nI just played a bit with this and with my proposed patch for\ngit-format-patch the signature is already part of the output:\n\n$ ./git-format-patch --complete HEAD^-\n0001-format-patch-add-complete.patch\n\n$ cat 0001-format-patch-add-complete.patch\n From ac30b08065cd55362a7244a3bbc8df3563cefaaa Mon Sep 17 00:00:00 2001\nFrom: Vegard Nossum \nDate: Sat, 5 Oct 2019 16:15:59 +0200\nSubject: [PATCH] format-patch: add --complete\n\nInclude the raw commit data between the changelog and the diffstat.\nThis will allow 'git am' to reconstruct the commit exactly to the point\nwhere the sha1 will be the same.\n\nSigned-off-by: Vegard Nossum \n---\ncommit ac30b08065cd55362a7244a3bbc8df3563cefaaa\ntree 8f09d9d6ed78f8617b2fe54fe9712990ba808546\nparent 108b97dc372828f0e72e56bbb40cae8e1e83ece6\nauthor Vegard Nossum 1570284959 +0200\ncommitter Vegard Nossum 1571408340 +0200\ngpgsig -----BEGIN PGP SIGNATURE-----\n Version: GnuPG v1\n\n iQIcBAABAgAGBQJdqcnVAAoJEAvO9Nj+mLpYPEMP/0qyUF6U9y6FMM3BQrjteGGY\n IEEwmkvfW8vMBdjXRjmSI1jxRUuW+xJs3kxezNuW79Gzkl63PlS3CdW50yLlWau6\n 2gU4R8oSNr7vxpgfAscELxaAuvUSp7Vb1FEPc5kPW06Sprg4PkLkUMD71ALRnGMV\n TxTVMDbMYg2xHpwBFs1ZyF2l0ElqOvRqoQqYfvRql1rgbs5LhF0RevkIN5xswj93\n 3Gz1CuB8MURX2lfglfYSTy/05Rx3w/QHxwNlbbPDtXrexySf+a70j/Z6i2/BIzR/\n kxlZJ/k4ZPN931mxFcLPBsV/K51uP378oEH1QdaZyO2jz1rj+AZxXlgXe8J3ZAmt\n XYT/FMze5lukd7EQDO5vPZazp1dnJ6wnmrAd8shCSWe23vybDMCYnjXTuwAXwbA5\n R7ffKxm3MwRn9LKsbHFiV0J8tS1/fHbOIEXQDJ+kFhKqys0RSXipDZU61LnogXaw\n 827TcsUYLvkYlQ+LdmSjZ537E+bUTo3Udb/UkGbgwSSm9LTjHnAI34S6dxSZ+1cl\n jBD54v8u9I1hEImWxGbXns7ET1fh17Z4PoTPpA4COt3puAQY7vB7inGY3/kWz+7z\n iRieHyD/W6lba4rqNYHBxacD4JTXN9S9Z7o6F4ijeGQThbA77RWD64SGjuJM0mC7\n mGUqvHz0pn7zOl1ZOS26\n =gCT0\n -----END PGP SIGNATURE-----\n\n---\n builtin/log.c | 12 ++++++++++++\n log-tree.c | 17 +++++++++++++++++\n revision.h | 3 ++-\n 3 files changed, 31 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/log.c b/builtin/log.c\nindex c4b35fdaf9..81c1164ae5 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -1545,6 +1545,7 @@ int cmd_format_patch(int argc, const char **argv, \nconst char *prefix)\n[...]\n\nThere is no corresponding support in 'git am' yet, however.\n\nSeeing how large this signature is, I have to admit that I am partial to\nKonstantin's suggestion of using minisign. This seems like something\nthat could be added to git as an alternative to gpg without too much\ntrouble, I think.\n\n\nVegard\n"},{"id":"384388","messageId":"20191018155047.id6r57komlejatvh@LykOS.localdomain","threadId":"52044","inReplyTo":"4ea21178-0cac-e958-7c69-ad5b4a74e6b5@gandi.net","subject":"Re: email as a bona fide git transport","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2019-10-18T15:50:48Z","receivedAt":"2019-10-18T15:50:52Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"\nOn Fri, Oct 18, 2019 at 08:34:17AM +0200, Nicolas Belouin wrote:\n> On 10/18/19 4:52 AM, Willy Tarreau wrote:\n> > On Thu, Oct 17, 2019 at 09:54:47PM -0400, Konstantin Ryabitsev wrote:\n> >> On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:\n> >>>> It could only possibly work if nobody ever adds their own\n> >>>> \"Signed-Off-By\" or\n> >>>> any other bylines. I expect this is a deal-breaker for most maintainers.\n> >>> Yeah it is :(\n> >>>\n> >>> But, if we could just have the signature on the code change, not the\n> >>> changelog text, that would help with that issue.\n> >> We totally should, and I even mused on how we would do that here:\n> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__public-2Dinbox.org_git_20190910121324.GA6867-40pure.paranoia.local_&d=DwICaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=yZMPY-APGKyVIX7HgQFZJA&m=-7NJMybpa_bV7Y1FxWmqo1cUHOsDXAsRR1vvpQmYhyI&s=iFHNwBfYAPr---qMdv0mvKQAxqjXxvf1mAiAYZG6DIE&e= \n> >>\n> >> However, since git's PGP signatures are made for the content in the actual\n> >> commit record (tree hash, parent, author, commit message, etc), the only way\n> >> we could preserve them between the email and the git tree is if we never\n> >> modify any of that data. The SOB and other trailers would have to only be\n> >> applied to the merge commit, or migrate into commit notes.\n> > There's also the possibility to handle this a bit like we do when adding\n> > comments before the SOB: a PGP signature would apply to the text *before*\n> > it only. We could then have long chains of SOB, PGP, SOB, PGP etc.\n> >\n> > Willy\n> \n> I don't think it can work that easily as the signed content is not just\n> the message.\n> It would need git to support nesting signatures and to allow amending a\n> commit without\n> touching the signature and to allow adding one to cover the new content\n> and to have a\n> way to verify every step.\n> Moreover you won't be able to reparent the commit as a maintainer (wich\n> I think is\n> also a deal-breaker)\n\nFor reference, we did something similar here[1]. I'll acknowledge it's\nsomewhat of a niche use, and there's a danger with multiple signature\ntypes that could mean many different things...\n\nI do wonder if an over-lying tool could probably provide with more\ngranular verification over mutiple gpg payloads inside of a commit...\n\nCheers!\n-Santiago.\n\n[1] https://dl.acm.org/citation.cfm?id=3196523\n"},{"id":"384389","messageId":"20191018160343.GB25456@chatter.i7.local","threadId":"52044","inReplyTo":"20191018155408.dk4tsjrne42ufpvv@LykOS.localdomain","subject":"Re: email as a bona fide git transport","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2019-10-18T16:03:43Z","receivedAt":"2019-10-18T16:03:50Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Fri, Oct 18, 2019 at 11:54:09AM -0400, Santiago Torres Arias wrote:\n>> Seeing how large this signature is, I have to admit that I am partial to\n>> Konstantin's suggestion of using minisign. This seems like something\n>> that could be added to git as an alternative to gpg without too much\n>> trouble, I think.\n>\n>I wonder how big the pgp payload would be with ed25519 as the underlying\n>algorithm. AFAICT, the payload of a minisign signature vs a signature\n>packet have almost the same fields...\n\nIt's smaller, but it's not a one-liner. Here's a comparison using \nED25519 keys of the same length:\n\nminisign:\n\nRWQ4kF9UdFgeSt3LqnS3WnrLlx2EnuIFW7euw5JnLUHY/79ipftmj7A2ug7FiR2WmnFNoSacWr7llBuyInVmRL/VRovj1LFtvA0=\n\npgp:\n\n-----BEGIN PGP SIGNATURE-----\n\niHUEARYIAB0WIQR2vl2yUnHhSB5njDW2xBzjVmSZbAUCXaniFAAKCRC2xBzjVmSZ\nbHA5AP46sSPFJfL2tbXwswvj0v2DjLAQ9doxl9bfj9iPZu+3qwEAw5qAMbjw9teL\nL7+NbJ0WVniDWTgt+5ruQ2V9vyfYxAc=\n=B/St\n-----END PGP SIGNATURE-----\n\n-K\n"},{"id":"384391","messageId":"20191018161121.6qe5kkweh4u77gvn@LykOS.localdomain","threadId":"52044","inReplyTo":"20191018160343.GB25456@chatter.i7.local","subject":"Re: email as a bona fide git transport","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2019-10-18T16:11:22Z","receivedAt":"2019-10-18T16:11:46Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"On Fri, Oct 18, 2019 at 12:03:43PM -0400, Konstantin Ryabitsev wrote:\n> On Fri, Oct 18, 2019 at 11:54:09AM -0400, Santiago Torres Arias wrote:\n> > > Seeing how large this signature is, I have to admit that I am partial to\n> > > Konstantin's suggestion of using minisign. This seems like something\n> > > that could be added to git as an alternative to gpg without too much\n> > > trouble, I think.\n> > \n> > I wonder how big the pgp payload would be with ed25519 as the underlying\n> > algorithm. AFAICT, the payload of a minisign signature vs a signature\n> > packet have almost the same fields...\n> \n> It's smaller, but it's not a one-liner. Here's a comparison using ED25519\n> keys of the same length:\n> \n> minisign:\n> \n> RWQ4kF9UdFgeSt3LqnS3WnrLlx2EnuIFW7euw5JnLUHY/79ipftmj7A2ug7FiR2WmnFNoSacWr7llBuyInVmRL/VRovj1LFtvA0=\n> \n> pgp:\n> \n> -----BEGIN PGP SIGNATURE-----\n> \n> iHUEARYIAB0WIQR2vl2yUnHhSB5njDW2xBzjVmSZbAUCXaniFAAKCRC2xBzjVmSZ\n> bHA5AP46sSPFJfL2tbXwswvj0v2DjLAQ9doxl9bfj9iPZu+3qwEAw5qAMbjw9teL\n> L7+NbJ0WVniDWTgt+5ruQ2V9vyfYxAc=\n> =B/St\n\nYeah, the discrepancy mostly comes from pgp embedding a timestamp and a\nlonger keyid (+a full keyid fingerprint in pgp 2.1+). Minisign keyids\nare 8 random bytes, apparently.\n\nIt doesn't seem like an amazing win in terms of succintness, imvho...\n\nCheers!\n-Santiago.\n"},{"id":"384392","messageId":"20191018161547.GG21137@mit.edu","threadId":"52044","inReplyTo":"56664222-6c29-09dc-ef78-7b380b113c4a@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2019-10-18T16:15:47Z","receivedAt":"2019-10-18T16:16:26Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Oct 18, 2019 at 04:27:48PM +0200, Vegard Nossum wrote:\n> commit ac30b08065cd55362a7244a3bbc8df3563cefaaa\n> tree 8f09d9d6ed78f8617b2fe54fe9712990ba808546\n> parent 108b97dc372828f0e72e56bbb40cae8e1e83ece6\n> author Vegard Nossum 1570284959 +0200\n> committer Vegard Nossum 1571408340 +0200\n> gpgsig -----BEGIN PGP SIGNATURE-----\n\t...\n\nWould it perhaps be possible to put some or all of these headers after\nthe patch, as a set of \"trailers\"? That would make it easier for\nhuman readers of the e-mail to get the bits that they most care\nabout.... namely, the patch itself. :-)\n\nIf we move the PGP signature to the end, then the fact that it is so\nbig and bulky becomes much less of an issue. A mini-sig might still\nbe a cool thing, from a space savings perspective both in the mail\narchives, and in the git repo itself, if we start signing all commits.\nBut that seems like a separable issue.\n\nThanks,\n\n\t\t\t\t\t- Ted\n"},{"id":"384396","messageId":"de49fe5e-85cb-9fb0-f9f4-c294d72e356c@oracle.com","threadId":"52044","inReplyTo":"20191018161547.GG21137@mit.edu","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-18T16:50:51Z","receivedAt":"2019-10-18T16:51:38Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"\nOn 10/18/19 6:15 PM, Theodore Y. Ts'o wrote:\n> On Fri, Oct 18, 2019 at 04:27:48PM +0200, Vegard Nossum wrote:\n>> commit ac30b08065cd55362a7244a3bbc8df3563cefaaa\n>> tree 8f09d9d6ed78f8617b2fe54fe9712990ba808546\n>> parent 108b97dc372828f0e72e56bbb40cae8e1e83ece6\n>> author Vegard Nossum 1570284959 +0200\n>> committer Vegard Nossum 1571408340 +0200\n>> gpgsig -----BEGIN PGP SIGNATURE-----\n> \t...\n> \n> Would it perhaps be possible to put some or all of these headers after\n> the patch, as a set of \"trailers\"? That would make it easier for\n> human readers of the e-mail to get the bits that they most care\n> about.... namely, the patch itself. :-)\n> \n\nYes, agreed.\n\nI started out using this approach, but I changed it because the\nimplementation was a bit annoying: 'git am' runs 'git mailsplit',\nwhich just splits the email into two parts:\n\n1) headers, changelog, and diffstat;\n2) diff and signature.\n\nOne of my PoC patches changes mailsplit to split the extra metadata into\na third file.\n\nThe problem I ran into with putting the metadata at the end was\ndetecting where the diff ends. A comment in 'git apply' suggested that\ndetecting the difference between \"--\" as a diff/signature separator and\nas part of the diff is nontrivial in the sense that you need to actually\ndo some parsing and keep track of hunk sizes.\n\nI can try to put it at the end, but maybe the git people have some hints\nthat would make the implementation easier? Is it okay to reimplement a\nsimple diff parser in mailsplit?\n\nThanks,\n\n\nVegard\n"},{"id":"384397","messageId":"20191018155408.dk4tsjrne42ufpvv@LykOS.localdomain","threadId":"52044","inReplyTo":"56664222-6c29-09dc-ef78-7b380b113c4a@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2019-10-18T15:54:09Z","receivedAt":"2019-10-18T17:22:46Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"> Seeing how large this signature is, I have to admit that I am partial to\n> Konstantin's suggestion of using minisign. This seems like something\n> that could be added to git as an alternative to gpg without too much\n> trouble, I think.\n> \n> \n\nI wonder how big the pgp payload would be with ed25519 as the underlying\nalgorithm. AFAICT, the payload of a minisign signature vs a signature\npacket have almost the same fields...\n"},{"id":"384398","messageId":"20191018180026.GD25456@chatter.i7.local","threadId":"52044","inReplyTo":"20191018161121.6qe5kkweh4u77gvn@LykOS.localdomain","subject":"Re: email as a bona fide git transport","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2019-10-18T18:00:26Z","receivedAt":"2019-10-18T18:00:33Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Fri, Oct 18, 2019 at 12:11:22PM -0400, Santiago Torres Arias wrote:\n>> It's smaller, but it's not a one-liner. Here's a comparison using \n>> ED25519\n>> keys of the same length:\n>>\n>> minisign:\n>>\n>> RWQ4kF9UdFgeSt3LqnS3WnrLlx2EnuIFW7euw5JnLUHY/79ipftmj7A2ug7FiR2WmnFNoSacWr7llBuyInVmRL/VRovj1LFtvA0=\n>>\n>> pgp:\n>>\n>> -----BEGIN PGP SIGNATURE-----\n>>\n>> iHUEARYIAB0WIQR2vl2yUnHhSB5njDW2xBzjVmSZbAUCXaniFAAKCRC2xBzjVmSZ\n>> bHA5AP46sSPFJfL2tbXwswvj0v2DjLAQ9doxl9bfj9iPZu+3qwEAw5qAMbjw9teL\n>> L7+NbJ0WVniDWTgt+5ruQ2V9vyfYxAc=\n>> =B/St\n>\n>Yeah, the discrepancy mostly comes from pgp embedding a timestamp and a\n>longer keyid (+a full keyid fingerprint in pgp 2.1+). Minisign keyids\n>are 8 random bytes, apparently.\n>\n>It doesn't seem like an amazing win in terms of succintness, imvho...\n\nThere isn't, but ED25519 subkeys are still very rare among developers. \nMany have 4096-bit RSA subkeys, and you can imagine how large the sigs \nfrom those are.\n\nI want to underline that my use of minisign was specifically for patches \nsent via email, without the intent of preserving them in git history \n(which is why in my proposal they are put under the `---` cutoff). Git \nitself would continue to use PGP signing.\n\n(This also means that we don't necessarily need to make this a native \npart of git -- it can be accomplished by a combination of wrappers, \ngit-format-patch parameters, and a pre-applypatch hook. However, the \nlikelihood of adoption in this case would be very low.)\n\n-K\n"},{"id":"384401","messageId":"20191018191456.GI21137@mit.edu","threadId":"52044","inReplyTo":"de49fe5e-85cb-9fb0-f9f4-c294d72e356c@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2019-10-18T19:14:56Z","receivedAt":"2019-10-18T19:15:37Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:\n> I started out using this approach, but I changed it because the\n> implementation was a bit annoying: 'git am' runs 'git mailsplit',\n> which just splits the email into two parts:\n> \n> 1) headers, changelog, and diffstat;\n> 2) diff and signature.\n> \n> One of my PoC patches changes mailsplit to split the extra metadata into\n> a third file.\n> \n> The problem I ran into with putting the metadata at the end was\n> detecting where the diff ends. A comment in 'git apply' suggested that\n> detecting the difference between \"--\" as a diff/signature separator and\n> as part of the diff is nontrivial in the sense that you need to actually\n> do some parsing and keep track of hunk sizes.\n\nCould we cheat by having \"git format-patch\" add a \"Diff-size\" in the\nheader which gives the number of lines in the diff so git am can just\ncount lines to find the Trailer section?\n\nThanks,\n\n\t\t\t\t\t- Ted\n"},{"id":"384467","messageId":"20191020031716.GA17475@1wt.eu","threadId":"52044","inReplyTo":"20191018191456.GI21137@mit.edu","subject":"Re: email as a bona fide git transport","fromName":"Willy Tarreau","fromEmail":"w@1wt.eu","sentAt":"2019-10-20T03:17:16Z","receivedAt":"2019-10-20T03:17:36Z","isPatch":false,"sender":{"key":"w@1wt.eu","avatar":"https://avatars.githubusercontent.com/u/8141789?v=4"},"body":"On Fri, Oct 18, 2019 at 03:14:56PM -0400, Theodore Y. Ts'o wrote:\n> On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:\n> > The problem I ran into with putting the metadata at the end was\n> > detecting where the diff ends. A comment in 'git apply' suggested that\n> > detecting the difference between \"--\" as a diff/signature separator and\n> > as part of the diff is nontrivial in the sense that you need to actually\n> > do some parsing and keep track of hunk sizes.\n> \n> Could we cheat by having \"git format-patch\" add a \"Diff-size\" in the\n> header which gives the number of lines in the diff so git am can just\n> count lines to find the Trailer section?\n\nBe careful with this, it starts like this and ends up with non-editable\npatches. I'd rather have git-am use best-effort detection of the end.\nAlso when dealing with stable backports, I've done a lot of\n\"cat foo.diff >> bar.patch\" to fixup some patches in which I just had\nto move some parts around. Having to count lines and edit a counter\nsomewhere is going to become really painful.\n\nJust my two cents,\nWilly\n"},{"id":"384468","messageId":"20191020055033.GD4991@pendragon.ideasonboard.com","threadId":"52044","inReplyTo":"20191018013029.GA1167832@kroah.com","subject":"Re: email as a bona fide git transport","fromName":"Laurent Pinchart","fromEmail":"laurent.pinchart@ideasonboard.com","sentAt":"2019-10-20T05:50:33Z","receivedAt":"2019-10-20T05:50:48Z","isPatch":false,"sender":{"key":"laurent.pinchart@ideasonboard.com","avatar":null},"body":"On Thu, Oct 17, 2019 at 06:30:29PM -0700, Greg KH wrote:\n> On Thu, Oct 17, 2019 at 04:45:32PM -0400, Konstantin Ryabitsev wrote:\n> > On Thu, Oct 17, 2019 at 01:43:43PM -0700, Greg KH wrote:\n> >>> I wonder if it'd be also possible to then embed gpg signatures over\n> >>> send-mail payloads so as they can be transparently transferred to the\n> >>> commit.\n> >> \n> >> That's a crazy idea. It would be nice if we could do that, I like it :)\n> > \n> > It could only possibly work if nobody ever adds their own \"Signed-Off-By\" or\n> > any other bylines. I expect this is a deal-breaker for most maintainers.\n> \n> Yeah it is :(\n> \n> But, if we could just have the signature on the code change, not the\n> changelog text, that would help with that issue.\n\nI ran into a related issue recently when thinking about how to implement\nserver-side workflows (for a non-kernel project). My goal is to ensure a\npatch can only be pushed to the master branch if it has received review.\nThe easy way to do so it to check the Reviewed-by tags, but those can\neasily be forged. I was thus wondering if we should have a way to sign\ntags (as in commit message tags, not git tags).\n\n-- \nRegards,\n\nLaurent Pinchart\n"},{"id":"384469","messageId":"1a259d8d-b3d1-b64e-07c3-ba143b42c442@oracle.com","threadId":"52044","inReplyTo":"20191020031716.GA17475@1wt.eu","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-20T06:28:31Z","receivedAt":"2019-10-20T06:29:24Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"\nOn 10/20/19 5:17 AM, Willy Tarreau wrote:\n> On Fri, Oct 18, 2019 at 03:14:56PM -0400, Theodore Y. Ts'o wrote:\n>> On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:\n>>> The problem I ran into with putting the metadata at the end was\n>>> detecting where the diff ends. A comment in 'git apply' suggested that\n>>> detecting the difference between \"--\" as a diff/signature separator and\n>>> as part of the diff is nontrivial in the sense that you need to actually\n>>> do some parsing and keep track of hunk sizes.\n>>\n>> Could we cheat by having \"git format-patch\" add a \"Diff-size\" in the\n>> header which gives the number of lines in the diff so git am can just\n>> count lines to find the Trailer section?\n> \n> Be careful with this, it starts like this and ends up with non-editable\n> patches. I'd rather have git-am use best-effort detection of the end.\n\nExpect filesystem developers to come up with a format that uses extents ;-)\n\n> Also when dealing with stable backports, I've done a lot of\n> \"cat foo.diff >> bar.patch\" to fixup some patches in which I just had\n> to move some parts around. Having to count lines and edit a counter\n> somewhere is going to become really painful.\n\nI almost have some new patches ready for putting the metadata after the\npatch using a very bare-bones diff parser (it's actually not that bad),\nI just need to fix a few corner cases that are causing breakage in the\ngit test suite.\n\n\nVegard\n"},{"id":"384601","messageId":"de6dd8b5-5c28-d0b2-d3fc-e72a6d643105@oracle.com","threadId":"52044","inReplyTo":"1a259d8d-b3d1-b64e-07c3-ba143b42c442@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-22T12:11:22Z","receivedAt":"2019-10-22T12:12:09Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"On 10/20/19 8:28 AM, Vegard Nossum wrote:\n> \n> On 10/20/19 5:17 AM, Willy Tarreau wrote:\n>> On Fri, Oct 18, 2019 at 03:14:56PM -0400, Theodore Y. Ts'o wrote:\n>>> On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:\n>>>> The problem I ran into with putting the metadata at the end was\n>>>> detecting where the diff ends. A comment in 'git apply' suggested that\n>>>> detecting the difference between \"--\" as a diff/signature separator and\n>>>> as part of the diff is nontrivial in the sense that you need to \n>>>> actually\n>>>> do some parsing and keep track of hunk sizes.\n>>>\n>>> Could we cheat by having \"git format-patch\" add a \"Diff-size\" in the\n>>> header which gives the number of lines in the diff so git am can just\n>>> count lines to find the Trailer section?\n>>\n>> Be careful with this, it starts like this and ends up with non-editable\n>> patches. I'd rather have git-am use best-effort detection of the end.\n> \n> Expect filesystem developers to come up with a format that uses extents ;-)\n> \n>> Also when dealing with stable backports, I've done a lot of\n>> \"cat foo.diff >> bar.patch\" to fixup some patches in which I just had\n>> to move some parts around. Having to count lines and edit a counter\n>> somewhere is going to become really painful.\n> \n> I almost have some new patches ready for putting the metadata after the\n> patch using a very bare-bones diff parser (it's actually not that bad),\n> I just need to fix a few corner cases that are causing breakage in the\n> git test suite.\n\nI sent v2 of the patches (with metadata _after_ the diff) to the git\nlist here:\n\nhttps://public-inbox.org/git/20191022114518.32055-1-vegard.nossum@oracle.com/T/#u\n\nAs I wrote in there, we could already today start using\n\n git am --message-id\n\nwhen applying patches and this would provide something that a bot could\nannotate with git notes pointing to lore/LKML/LWN/whatever. I think that\nwould already be a pretty nice improvement over today's situation.\n\nSadly, since the beginning of 2018, this was only used for a measly\n~0.14% of all non-merge commits in the kernel:\n\n$ git rev-list --count --no-merges --since='2018-01-01' --grep \n'Message-Id: ' linus/master\n178\n\n$ git rev-list --count --no-merges --since='2018-01-01' linus/master\n130777\n\nSo how can we spread the word about --message-id and get maintainers to\nactually use it? I don't suppose it's reasonable to change the 'git am'\ndefault setting?\n\n\nVegard\n"},{"id":"384603","messageId":"20191022135344.GC23268@mit.edu","threadId":"52044","inReplyTo":"de6dd8b5-5c28-d0b2-d3fc-e72a6d643105@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2019-10-22T13:53:44Z","receivedAt":"2019-10-22T13:54:31Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote:\n> \n> As I wrote in there, we could already today start using\n> \n> git am --message-id\n> \n> when applying patches and this would provide something that a bot could\n> annotate with git notes pointing to lore/LKML/LWN/whatever. I think that\n> would already be a pretty nice improvement over today's situation.\n> \n> Sadly, since the beginning of 2018, this was only used for a measly\n> ~0.14% of all non-merge commits in the kernel:\n> \n> $ git rev-list --count --no-merges --since='2018-01-01' --grep 'Message-Id:\n> ' linus/master\n> 178\n\nYou might also want to count commits which have a link tag with a\nMessage-Id:\n\nLink: https://lore.kernel.org/r/c3438dad66a34a7d4e7509a5dd64c2326340a52a.1571647180.git.mbobrowski@mbobrowski.org\n\nThat's because some kernel developers have been using a hook script like this:\n\n#!/bin/sh\n# For .git/hooks/applypatch-msg\n#\n# You must have the following in .git/config:\n# [am]\n#\tmessageid = true\n\t\n. git-sh-setup\nperl -pi -e 's|^Message-Id:\\s*]+)>?$|Link: https://lore.kernel.org/r/$1|g;' \"$1\"\ntest -x \"$GIT_DIR/hooks/commit-msg\" &&\n\texec \"$GIT_DIR/hooks/commit-msg\" ${1+\"$@\"}\n:\n\n.... as we had reached rough consensus that this was the best way to\nincorprate the message id (since it could made to be a clickable link\nin tools like gitk, for example). This rough consensus has only been\nin place since around the time of the Maintainer's Summit in Lisbon,\nso uptake is still probably a bit slow. I'd expect to see a lot more\nof this in the next merge window, though.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"384611","messageId":"eed119a2-1561-131e-9d3d-d4d5aadee825@oracle.com","threadId":"52044","inReplyTo":"20191022135344.GC23268@mit.edu","subject":"Re: email as a bona fide git transport","fromName":"Vegard Nossum","fromEmail":"vegard.nossum@oracle.com","sentAt":"2019-10-22T16:29:34Z","receivedAt":"2019-10-22T16:30:25Z","isPatch":false,"sender":{"key":"vegard.nossum@oracle.com","avatar":"https://avatars.githubusercontent.com/u/24173?v=4"},"body":"\nOn 10/22/19 3:53 PM, Theodore Y. Ts'o wrote:\n> On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote:\n>>\n>> As I wrote in there, we could already today start using\n>>\n>> git am --message-id\n>>\n>> when applying patches and this would provide something that a bot could\n>> annotate with git notes pointing to lore/LKML/LWN/whatever. I think that\n>> would already be a pretty nice improvement over today's situation.\n>>\n>> Sadly, since the beginning of 2018, this was only used for a measly\n>> ~0.14% of all non-merge commits in the kernel:\n>>\n>> $ git rev-list --count --no-merges --since='2018-01-01' --grep 'Message-Id:\n>> ' linus/master\n>> 178\n> \n> You might also want to count commits which have a link tag with a\n> Message-Id:\n> \n> Link: https://lore.kernel.org/r/c3438dad66a34a7d4e7509a5dd64c2326340a52a.1571647180.git.mbobrowski@mbobrowski.org\n> \n> That's because some kernel developers have been using a hook script like this:\n> \n> #!/bin/sh\n> # For .git/hooks/applypatch-msg\n> #\n> # You must have the following in .git/config:\n> # [am]\n> #\tmessageid = true\n> \t\n> . git-sh-setup\n> perl -pi -e 's|^Message-Id:\\s*]+)>?$|Link: https://lore.kernel.org/r/$1|g;' \"$1\"\n> test -x \"$GIT_DIR/hooks/commit-msg\" &&\n> \texec \"$GIT_DIR/hooks/commit-msg\" ${1+\"$@\"}\n> :\n> \n> .... as we had reached rough consensus that this was the best way to\n> incorprate the message id (since it could made to be a clickable link\n> in tools like gitk, for example). This rough consensus has only been\n> in place since around the time of the Maintainer's Summit in Lisbon,\n> so uptake is still probably a bit slow. I'd expect to see a lot more\n> of this in the next merge window, though.\n\nThanks, I was not aware of this!\n\nSeems like something that should go in Documentation/maintainer/,\nright?\n\nThe figure is much better, 16.7% on all non-merges since 2018-01-01.\nThis should help and we can maybe already do some interesting things\nwith git notes and lore/public-inbox.\n\n\nVegard\n"},{"id":"384618","messageId":"20191022190127.GA697@dcvr","threadId":"52044","inReplyTo":"de6dd8b5-5c28-d0b2-d3fc-e72a6d643105@oracle.com","subject":"Re: email as a bona fide git transport","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2019-10-22T19:01:27Z","receivedAt":"2019-10-22T19:01:31Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Vegard Nossum wrote:\n> I sent v2 of the patches (with metadata _after_ the diff) to the git\n> list here:\n> \n> https://public-inbox.org/git/20191022114518.32055-1-vegard.nossum@oracle.com/T/#u\n> \n> As I wrote in there, we could already today start using\n> \n> git am --message-id\n> \n> when applying patches and this would provide something that a bot could\n> annotate with git notes pointing to lore/LKML/LWN/whatever. I think that\n> would already be a pretty nice improvement over today's situation.\n> \n> Sadly, since the beginning of 2018, this was only used for a measly\n> ~0.14% of all non-merge commits in the kernel:\n\n--message-id helps provide a concrete reference, yes. However,\nbeing able to search for commit subjects in the mail archives is\nalready implemented via cgit filter. An example is here:\n\nhttps://80x24.org/mirrors/git.git/commit/?id=8da56a484800023a545d7a7c022473f5aa9e720f\n\nThe link at \"userdiff: fix some corner cases in dts regex\" makes a link to:\n\nhttps://public-inbox.org/git/?x=t&q=%22userdiff:+fix+some+corner+cases+in+dts+regex%22\n(side note: not sure if that \"x=t\" to expand the whole message is good...)\n\nThat link is generated by examples/cgit-commit-filter.lua in the\n public-inbox source:\n\nhttps://public-inbox.org/meta/1677253/s/?b=examples/cgit-commit-filter.lua\n\nMy longer term plan is to be able to use the post-image blob OIDs\nfrom cgit to generate a search query for public-inbox such as:\n\nhttps://public-inbox.org/git/?q=dfpost:afc6b5b404+dfpost:072d58b69d+dfpost:4353b8220c+dfpost:333a625c70+dfpost:e187d356f6\n\nWhich finds all versions of the userdiff patch posted. But AFAIK\nthere's no easy way to get at blob OIDs from cgit to a Lua filter...\n"}]}