{"thread":{"id":"41981","subject":"[PATCH 0/4] support for ack commits","startedAt":"2016-04-10T13:54:42Z","lastAt":"2016-04-12T20:00:25Z","messageCount":17,"participants":["Michael S. Tsirkin","Johannes Schindelin","Christian Neukirchen","Junio C Hamano","Matthieu Moy"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"283093","messageId":"1460296343-17304-1-git-send-email-mst@redhat.com","threadId":"41981","inReplyTo":null,"subject":"[PATCH 0/4] support for ack commits","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-10T13:54:42Z","receivedAt":"2016-04-10T13:54:42Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"This is a repost after rebasing, and addressing comments by Eric Sunshine and\nFabian Ruch. I'd like to try getting this upstream so I can stop maintaining\nit. So reposting - rebased to latest master, with a better motivation in the\ncover letter.\n\nAs a maintainer, I get patches by mail, then\nacked-by,reviewed-by etc responses are sent by separate\nmail.\n\nThe result is that I have a patch applied, and now\nI need to find it and apply the ack responses to it.\n\nThe flow I use to handle this, is to record an\nempty commit (which I'm calling an ack commit)\nwith just the ack in the log, and ack! tag\nand the subject of the original patch in the\nsubject.\n\nSometimes, I would also make a small change with\nthat ack commit, typically using commit --amend,\nfor example if the ack mail says:\n\n\tSubject: Re: [PATCH] xyz\n\n\tplease rename xyz to foo. With that:\n\n\tAcked-by: Michael S. Tsirkin \n\nI would apply ack and make the change as part of that.\n\nLater, once in a while I rebase and squash the ack commits\ninto the regular one: the rebase autosquash mechanics\nfind the original commit and update the commit log,\nappending the ack.\n\nfrom example, we start with an email:\n\tFrom: Michael S. Tsirkin \n\tSubject: [PATCH] foo.c: change b to c\n\tDate: Wed Apr 6 22:07:34 2016 +0300\n\n\t foo.c: change b to c\n\t \n\t Change BBBBBBBBBBBBBBBBB to CCCCCCCCCCCCCCCCC\n\t \n\t Signed-off-by: Michael S. Tsirkin \n\n\t---\n\n\tdiff --git a/foo.c b/foo.c\n\tindex 8e5be91..34654fc 100644\n\t--- a/foo.c\n\t+++ b/foo.c\n\t@@ -676,6 +676,6 @@ FFFFFFFFFFFFFFFFFFFFFFF(\n\t\tAAAAAAAAAAAAAAAAAAAAAAAAA\n\t \n\t- BBBBBBBBBBBBBBBBB\n\t- BBBBBBBBBBBBBBBBB\n\t+ CCCCCCCCCCCCCCCCC\n\t+ CCCCCCCCCCCCCCCCC\n\n\t\tDDDDDDDDDDDDDDDDD\n\nand I apply it using git am.\n\n\nthen I get an email:\n\n\tSubject: Re: [PATCH] foo.c: change b to c\n\n > \t foo.c: change b to c\n > \t \n > \t Change BBBBBBBBBBBBBBBBB to CCCCCCCCCCCCCCCCC\n > \t \n > \t Signed-off-by: Michael S. Tsirkin \n > \n > \t---\n > \n > \tdiff --git a/foo.c b/foo.c\n > \tindex 8e5be91..34654fc 100644\n > \t--- a/foo.c\n > \t+++ b/foo.c\n > \t@@ -676,6 +676,6 @@ FFFFFFFFFFFFFFFFFFFFFFF(\n > \t\tAAAAAAAAAAAAAAAAAAAAAAAAA\n > \t \n > \t- BBBBBBBBBBBBBBBBB\n > \t- BBBBBBBBBBBBBBBBB\n > \t+ CCCCCCCCCCCCCCCCC\n > \t+ CCCCCCCCCCCCCCCCC\n > \n > \t\tDDDDDDDDDDDDDDDDD\n\t \n\tAcked-by: Junio C Hamano \n\nI then create an empty commit using the subject and the ack line:\n\n\tcommit 4d54b237d8d03323933e27119272e93cf33b4e98\n\tAuthor: Michael S. Tsirkin \n\tDate: Wed Apr 6 22:07:34 2016 +0300\n\n\tack! foo.c: change b to c\n\n\tAcked-by: Junio C Hamano \n\n(with no change) and then after rebase -i --autosquash it is combined\nwith the original commit by squashing changes (easy as the\nsecond one has an empty change), and appending the commit log\nfrom the second one to first one:\n\ncommit ef7b6d457c28bcd06d0118a889c7070fc800f3d5\nAuthor: Michael S. Tsirkin \nDate: Wed Apr 6 14:55:59 2016 +0300\n\n foo.c: change b to c\n \n Change BBBBBBBBBBBBBBBBB to CCCCCCCCCCCCCCCCC\n \n Signed-off-by: Michael S. Tsirkin \n Acked-by: Junio C Hamano \n\ndiff --git a/foo.c b/foo.c\nindex 8e5be91..34654fc 100644\n--- a/foo.c\n+++ b/foo.c\n@@ -676,6 +676,6 @@ FFFFFFFFFFFFFFFFFFFFFFF(\n\tAAAAAAAAAAAAAAAAAAAAAAAAA\n \n- BBBBBBBBBBBBBBBBB\n- BBBBBBBBBBBBBBBBB\n+ CCCCCCCCCCCCCCCCC\n+ CCCCCCCCCCCCCCCCC\n\n\tDDDDDDDDDDDDDDDDD\n\n\nThe empty ack commits can be created by hand. I have also\nwritten a small script for that - included\nas patch 4/4 but it is still rather rough so only putting it\nunder contrib for now - would like to try\nand merge the rebase machinery in place first.\nLong term, it might be cleaner to teach git-am about an --ack flag.\nBut it is already helpful to explain how this is intended to be used.\nThat script can be used in one of two ways:\n\n\t1. pipe the mail with ack to it. we extract\n\t subject and prepend ack!, extract the ack\n\t trailer line that needs to be appended to commit,\n\t and record the result as en empty commit.\n\t2. pipe the mail with ack to it with flag -s,\n\t this saves the ack trailer into a file.\n then pipe the original patch(es) to it\n with flag -r, now the subject is taken from\n patch, with ack! prepended, but the ack trailer\n is from the ack email.\n this is useful to handle series acks, similar to:\n\t\t For series:\n\t\t\tAcked-by: Michael S. Tsirkin \n\n\n\nSo what is an ack commit from point of view of rebase?\n\n1. subject is ack! \n\n2. commit can be empty and it does not mean it needs to be skipped\n\n3. when squashing into parent commit, subject and empty line\n after it should be skipped, and the rest of commit log\n should be appended to commit log of parent, as is.\n\n\nI have been using these patches without any problems for more than a\nyear now, and find the approach very convenient.\n\nIncluded:\n rebase: new ack! action to handle ack commits\n this part seems ready for merge to me,\n please review and comment\n\n git-ack: new tool to record an ack\n this does not have proper documentation\n and tests yet, I definitely intend to\n do this but wanted to see whether people\n like the UI first.\n posting for early review and feedback\n\n\nNote: people mostly using pull requests for communication\nwill not find this approach useful.\nAs it's optional, this should not be a problem.\n\nNote: it was suggested that \"squash! --noedit\" would be easier\nto maintain than \"ack!\" - I think this would be less\nuser-friendly, so I left this suggestion out for now.\n\n\nMichael S. Tsirkin (4):\n rebase -i: add ack action\n git-rebase: document ack\n rebase: test ack\n git-ack: record an ack\n\n Documentation/git-rebase.txt | 45 +++++++++++++++++++---\n contrib/git-ack | 90 ++++++++++++++++++++++++++++++++++++++++++++\n git-rebase--interactive.sh | 36 ++++++++++++++----\n t/t3415-rebase-autosquash.sh | 15 ++++++++\n 4 files changed, 173 insertions(+), 13 deletions(-)\n create mode 100755 contrib/git-ack\n\n-- \nMST\n"},{"id":"283094","messageId":"1460296343-17304-2-git-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"1460296343-17304-1-git-send-email-mst@redhat.com","subject":"[PATCH 1/4] rebase -i: add ack action","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-10T13:54:45Z","receivedAt":"2016-04-10T13:54:45Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"This implements a new ack! action for git rebase -i\nIt is essentially a middle ground between fixup! and squash!:\n- commits are squashed silently without editor being started\n- commit logs are concatenated (with action line being discarded)\n- because of the above, empty commits aren't discarded,\n their log is also included.\n\nI am using it as follows:\n\tgit am -s < mailbox #creates first commit\n\thack ...\n\tget mail with Ack\n\tgit commit --allow-empty -m `cat <<-EOF\n\tack! first\n\n\tAcked-by: maintainer\n\tEOF`\n\trepeat cycle\n\tgit rebase --autosquash -i origin/master\n\tbefore public branch push\n\nThe \"cat\" command above is actually a script that\nparses the Ack mail to create the empty commit -\nto be submitted separately.\n\nSigned-off-by: Michael S. Tsirkin \n---\n git-rebase--interactive.sh | 36 ++++++++++++++++++++++++++++--------\n 1 file changed, 28 insertions(+), 8 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 4cde685..6a766ca 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -150,6 +150,7 @@ Commands:\n r, reword = use commit, but edit the commit message\n e, edit = use commit, but stop for amending\n s, squash = use commit, but meld into previous commit\n+ a, ack = like \"squash\", but append commit body only to previous commit\n f, fixup = like \"squash\", but discard this commit's log message\n x, exec = run command (the rest of the line) using shell\n d, drop = remove commit\n@@ -438,6 +439,15 @@ update_squash_messages () {\n \t\techo\n \t\tcommit_message $2\n \t\t;;\n+\tack)\n+\t\tif test -f \"$fixup_msg\"\n+\t\tthen\n+\t\t\tcommit_message $2 | git stripspace --strip-comments | sed -e '1,2d' >> \"$fixup_msg\"\n+\t\tfi\n+\t\tprintf '%s\\n' \"$comment_char This is the $(nth_string $count) commit message:\"\n+\t\techo\n+\t\tcommit_message $2\n+\t\t;;\n \tfixup)\n \t\techo\n \t\tprintf '%s\\n' \"$comment_char The $(nth_string $count) commit message will be skipped:\"\n@@ -479,7 +489,7 @@ record_in_rewritten() {\n \techo \"$oldsha1\" >> \"$rewritten_pending\"\n \n \tcase \"$(peek_next_command)\" in\n-\tsquash|s|fixup|f)\n+\tsquash|s|fixup|f|ack|a)\n \t\t;;\n \t*)\n \t\tflush_rewritten_pending\n@@ -551,8 +561,11 @@ do_next () {\n \t\twarn \"Stopped at $sha1... $rest\"\n \t\texit_with_patch $sha1 0\n \t\t;;\n-\tsquash|s|fixup|f)\n+\tsquash|s|fixup|f|ack|a)\n \t\tcase \"$command\" in\n+\t\tack|a)\n+\t\t\tsquash_style=ack\n+\t\t\t;;\n \t\tsquash|s)\n \t\t\tsquash_style=squash\n \t\t\t;;\n@@ -576,7 +589,7 @@ do_next () {\n \t\t\tdie_failed_squash $sha1 \"$rest\"\n \t\tfi\n \t\tcase \"$(peek_next_command)\" in\n-\t\tsquash|s|fixup|f)\n+\t\tsquash|s|fixup|f|ack|a)\n \t\t\t# This is an intermediate commit; its message will only be\n \t\t\t# used in case of trouble. So use the long version:\n \t\t\tdo_with_author output git commit --amend --no-verify -F \"$squash_msg\" \\\n@@ -587,7 +600,7 @@ do_next () {\n \t\t\t# This is the final command of this squash/fixup group\n \t\t\tif test -f \"$fixup_msg\"\n \t\t\tthen\n-\t\t\t\tdo_with_author git commit --amend --no-verify -F \"$fixup_msg\" \\\n+\t\t\t\tdo_with_author git commit --quiet --amend --no-verify -F \"$fixup_msg\" \\\n \t\t\t\t\t${gpg_sign_opt:+\"$gpg_sign_opt\"} ||\n \t\t\t\t\tdie_failed_squash $sha1 \"$rest\"\n \t\t\telse\n@@ -717,7 +730,7 @@ skip_unnecessary_picks () {\n \tdone <\"$todo\" >\"$todo.new\" 3>>\"$done\" &&\n \tmv -f \"$todo\".new \"$todo\" &&\n \tcase \"$(peek_next_command)\" in\n-\tsquash|s|fixup|f)\n+\tsquash|s|fixup|f|ack|a)\n \t\trecord_in_rewritten \"$onto\"\n \t\t;;\n \tesac ||\n@@ -764,7 +777,7 @@ rearrange_squash () {\n \tdo\n \t\ttest -z \"${format}\" || message=$(git log -n 1 --format=\"%s\" ${sha1})\n \t\tcase \"$message\" in\n-\t\t\"squash! \"*|\"fixup! \"*)\n+\t\t\"squash! \"*|\"fixup! \"*|\"ack! \"*)\n \t\t\taction=\"${message%%!*}\"\n \t\t\trest=$message\n \t\t\tprefix=\n@@ -772,7 +785,7 @@ rearrange_squash () {\n \t\t\twhile :\n \t\t\tdo\n \t\t\t\tcase \"$rest\" in\n-\t\t\t\t\"squash! \"*|\"fixup! \"*)\n+\t\t\t\t\"squash! \"*|\"fixup! \"* |\"ack! \"*)\n \t\t\t\t\tprefix=\"$prefix${rest%%!*},\"\n \t\t\t\t\trest=\"${rest#*! }\"\n \t\t\t\t\t;;\n@@ -904,7 +917,7 @@ check_bad_cmd_and_sha () {\n \t\t\t# Work around CR left by \"read\" (e.g. with Git for\n \t\t\t# Windows' Bash).\n \t\t\t;;\n-\t\tpick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)\n+\t\tpick|p|drop|d|reword|r|edit|e|squash|s|fixup|f|ack|a)\n \t\t\tif ! check_commit_sha \"${rest%%[ \t]*}\" \"$lineno\" \"$1\"\n \t\t\tthen\n \t\t\t\tretval=1\n@@ -1196,6 +1209,13 @@ do\n \t\tcomment_out=\n \tfi\n \n+\t# keep empty ack! commits around: useful to add text to commit log\n+\tcase \"$rest\" in\n+\t\"ack! \"*)\n+\t\tcomment_out=\n+\t\t;;\n+\tesac\n+\n \tif test t != \"$preserve_merges\"\n \tthen\n \t\tprintf '%s\\n' \"${comment_out}pick $sha1 $rest\" >>\"$todo\"\n-- \nMST\n"},{"id":"283096","messageId":"1460296343-17304-3-git-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"1460296343-17304-1-git-send-email-mst@redhat.com","subject":"[PATCH 2/4] git-rebase: document ack","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-10T13:54:47Z","receivedAt":"2016-04-10T13:54:47Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"document ack! behaviour and use\n\nSigned-off-by: Michael S. Tsirkin \n---\n Documentation/git-rebase.txt | 45 +++++++++++++++++++++++++++++++++++++++-----\n 1 file changed, 40 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 0387b40..257d75c 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -402,7 +402,7 @@ or by giving more than one `--exec`:\n +\n If `--autosquash` is used, \"exec\" lines will not be appended for\n the intermediate commits, and will only appear at the end of each\n-squash/fixup series.\n+squash/fixup/ack series.\n +\n This uses the `--interactive` machinery internally, but it can be run\n without an explicit `--interactive`.\n@@ -419,13 +419,13 @@ without an explicit `--interactive`.\n \n --autosquash::\n --no-autosquash::\n-\tWhen the commit log message begins with \"squash! ...\" (or\n-\t\"fixup! ...\"), and there is a commit whose title begins with\n+\tWhen the commit log message begins with \"squash! ...\" (\"fixup! ...\"\n+\tor \"ack! ...\"), and there is a commit whose title begins with\n \tthe same ..., automatically modify the todo list of rebase -i\n \tso that the commit marked for squashing comes right after the\n \tcommit to be modified, and change the action of the moved\n-\tcommit from `pick` to `squash` (or `fixup`). Ignores subsequent\n-\t\"fixup! \" or \"squash! \" after the first, in case you referred to an\n+\tcommit from `pick` to `squash` (`fixup` or `ack`). Ignores subsequent\n+\t\"ack! \", \"fixup! \" or \"squash! \" after the first, in case you referred to an\n \tearlier fixup/squash with `git commit --fixup/--squash`.\n +\n This option is only valid when the '--interactive' option is used.\n@@ -649,6 +649,41 @@ consistent (they compile, pass the testsuite, etc.) you should use\n 'git stash' to stash away the not-yet-committed changes\n after each commit, test, and amend the commit if fixes are necessary.\n \n+----------------\n+RECORDING ACKS\n+----------------\n+\n+Interactive mode with --autosquash can be used to concatenate\n+commit log for several commits, which is useful to record\n+extra information about the commit, such as ack signatures.\n+This allows, for example, the following workflow:\n+\n+1. receive patches by mail and commit\n+2. receive by mail ack signatures for the patches\n+3. prepare a series for submission\n+4. submit\n+\n+where point 2. consists of several instances of\n+\ti) create a (possibly empty) commit with signature\n+\t in the commit message\n+\n+Sometimes the ack signature added in i. cannot be amended to the\n+commit it acks, because that commit is buried deeply in a\n+patch series. That is exactly what rebase --autosquash\n+option is for: use it\n+after plenty of \"i\"s, to automaticlly rearrange\n+commits, and squashing multiple sign-off commits into\n+the commit that is signed.\n+\n+Start it with the last commit you want to retain as-is:\n+\n+\tgit rebase --autosquash -i \n+\n+An editor will be fired up with all the commits in your current branch\n+which come after the given commit. Ack commits will be\n+re-arranged to come after the commit that is acked,\n+and the action will be automatically changed from `pick` to `ack`\n+to cause them to be squashed into the acked commit.\n \n RECOVERING FROM UPSTREAM REBASE\n -------------------------------\n-- \nMST\n"},{"id":"283095","messageId":"1460296343-17304-4-git-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"1460296343-17304-1-git-send-email-mst@redhat.com","subject":"[PATCH 3/4] rebase: test ack","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-10T13:54:50Z","receivedAt":"2016-04-10T13:54:50Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"test ack! handling\n\nSigned-off-by: Michael S. Tsirkin \n---\n t/t3415-rebase-autosquash.sh | 15 +++++++++++++++\n 1 file changed, 15 insertions(+)\n\ndiff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh\nindex 8f53e54..e78897d 100755\n--- a/t/t3415-rebase-autosquash.sh\n+++ b/t/t3415-rebase-autosquash.sh\n@@ -74,6 +74,21 @@ test_expect_success 'auto squash (option)' '\n \ttest_auto_squash final-squash --autosquash\n '\n \n+test_expect_success 'auto ack' '\n+\tack=\"Acked-by: xyz\" &&\n+\tmsg=$(test_write_lines \"ack! first commit\" \"\" \"$ack\") &&\n+\tgit reset --hard base &&\n+\tgit commit --allow-empty -m \"$msg\" -- &&\n+\tgit tag ack &&\n+\ttest_tick &&\n+\tgit rebase --autosquash -i HEAD^^^ &&\n+\tgit log --oneline >actual &&\n+\tgit show -s first-commit | grep -v ^commit > expected-msg &&\n+\techo \" $ack\" >> expected-msg &&\n+\tgit show -s HEAD^ | grep -v ^commit > actual-msg &&\n+\tdiff actual-msg expected-msg\n+'\n+\n test_expect_success 'auto squash (config)' '\n \tgit config rebase.autosquash true &&\n \ttest_auto_squash final-squash-config-true &&\n-- \nMST\n"},{"id":"283097","messageId":"1460296343-17304-5-git-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"1460296343-17304-1-git-send-email-mst@redhat.com","subject":"[PATCH 4/4] git-ack: record an ack","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-10T13:54:52Z","receivedAt":"2016-04-10T13:54:52Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"This is a simple script that I use by piping\nincoming mail with an ack to it.\nIt produces an empty ack commit suitable for\nsqushing with git rebase -i -autosquash.\n\nWorks best if people ack individual commits: you simply\npipe each ack to git ack, before pushing your branch,\nrebase.\n\nSome people ack series by responding to cover letter\nor to commit 1.\nTo address this usecase, there are two additional\nflags: -s saves the ack signature in a file (you can\nsave several in a row), -r creates an ack for\na given patch using the saved signature.\nThus: pipe ack(s) to git ack -s, then select and pipe\neach individual patch to git ack -r.\n\nIf it's found useful, this script can either\nbecome a first-class command (with documentation\nand tests) or be integrated as a flag into git am.\n\nLimitations: requires that index is clean, this is\nso we can create an empty commit recording the ack.\n\nSigned-off-by: Michael S. Tsirkin \n---\n contrib/git-ack | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 91 insertions(+)\n create mode 100755 contrib/git-ack\n\ndiff --git a/contrib/git-ack b/contrib/git-ack\nnew file mode 100755\nindex 0000000..d8cba95\n--- /dev/null\n+++ b/contrib/git-ack\n@@ -0,0 +1,91 @@\n+msg=$(mktemp)\n+patch=$(mktemp)\n+info=$(git mailinfo $msg $patch)\n+subj=$(echo \"$info\" | sed -n 's/^Subject: //p')\n+#strip ack!/fixup!/squash! prefix\n+subj=$(echo \"$subj\" | sed \"s/^fixup![ \t]*//\")\n+subj=$(echo \"$subj\" | sed \"s/^squash![ \t]*//\")\n+subj=$(echo \"$subj\" | sed \"s/^ack![ \t]*//\")\n+author=$(echo \"$info\" | sed -n 's/^Author: //p')\n+email=$(echo \"$info\" | sed -n 's/^Email: //p')\n+auth=\"$author <$email>\"\n+date=$(echo \"$info\" | sed -n 's/^Date: //p')\n+sign=$(mktemp)\n+echo \"ack! $subj\" >\"$sign\"\n+echo \"\" >> $sign\n+if\n+\tgit diff --exit-code --cached HEAD\n+then\n+\t:\n+else\n+\techo \"DIFF in cache. Not acked, reset or commit!\"\n+\texit 1\n+fi\n+GIT_DIR=$(git rev-parse --git-dir)\n+\n+usage () {\n+\techo \"Usage: git ack \" \\\n+\t\t\"[-s|--save|-a|--append|-r|--restore |-c|--clear]\\n\" >&2;\n+\texit 1;\n+}\n+\n+append=\n+save=\n+clear=\n+restore=\n+\n+while test $# != 0\n+do\n+\tcase \"$1\" in\n+\t-a|--append)\n+\t\tappend=\"y\"\n+\t\t;;\n+\t-s|--s)\n+\t\tsave=\"y\"\n+\t\t;;\n+\t-r|--restore)\n+\t\trestore=\"y\"\n+\t\t;;\n+\t-c|--clear)\n+\t\tclear=\"y\"\n+\t\t;;\n+\t*)\n+\t\tusage ;;\n+\tesac\n+\tshift\n+done\n+\n+if\n+\ttest \"$clear\"\n+then\n+\trm -f \"${GIT_DIR}/ACKS\"\n+fi\n+\n+if\n+\ttest \"$save\"\n+then\n+\tif\n+\t\ttest \"$append\"\n+\tthen\n+\t\tcat $msg >>\"${GIT_DIR}/ACKS\"\n+\telse\n+\t\tcat $msg >\"${GIT_DIR}/ACKS\"\n+\tfi\n+\texit 0\n+fi\n+\n+if\n+\ttest \"$restore\"\n+then\n+\tmsg=${GIT_DIR}/ACKS\n+fi\n+\n+echo $msg > /dev/tty\n+if\n+\tgrep '^[A-Z][A-Za-z-]*-by:' $msg >> $sign\n+then\n+\tgit commit --allow-empty -F $sign --author=\"$auth\" --date=\"$date\"\n+else\n+\techo \"No signature found!\"\n+\texit 2\n+fi\n-- \nMST\n"},{"id":"283133","messageId":"alpine.DEB.2.20.1604111239100.2967@virtualbox","threadId":"41981","inReplyTo":"1460296343-17304-2-git-send-email-mst@redhat.com","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-04-11T11:02:07Z","receivedAt":"2016-04-11T11:02:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Michael,\n\nOn Sun, 10 Apr 2016, Michael S. Tsirkin wrote:\n\n> This implements a new ack! action for git rebase -i\n> It is essentially a middle ground between fixup! and squash!:\n> - commits are squashed silently without editor being started\n> - commit logs are concatenated (with action line being discarded)\n> - because of the above, empty commits aren't discarded,\n> their log is also included.\n> \n> I am using it as follows:\n> \tgit am -s < mailbox #creates first commit\n> \thack ...\n> \tget mail with Ack\n> \tgit commit --allow-empty -m `cat <<-EOF\n> \tack! first\n> \n> \tAcked-by: maintainer\n> \tEOF`\n> \trepeat cycle\n> \tgit rebase --autosquash -i origin/master\n> \tbefore public branch push\n> \n> The \"cat\" command above is actually a script that\n> parses the Ack mail to create the empty commit -\n> to be submitted separately.\n\nThis looks awfully complicated, still, and not very generic.\n\nHow about making it easier to use, and much, much more generic, like this?\n\n1. introducing an `--add-footer` flag to `git commit` that you could use\nlike this:\n\n\tgit commit --amend --add-footer \"Acked-by: Bugs Bunny\"\n\n2. introducing an `--exec-after` flag to `git commit` that would be a new\nsibling of `--fixup` and `--squash` and would work like this:\n\n\tgit commit --exec-after HEAD~5 \\\n\t\t'git commit --amend --add-footer \"Acked-by: Bugs Bunny\"'\n\n(it should imply `--allow-empty`, of course, and probably even fail if\nanything was staged for commit at that point.) The commit message would\nthen look something like\n\n\texec-after! Fix broken breakage\n\n\tgit commit --amend --add-footer \"Acked-by: Bugs Bunny\"\n\nThis way would obviously benefit a lot more users. For example, you could\neasily say (and alias)\n\n\tgit commit --amend --add-footer 'Reviewed-by: Arrested Developer\"\n\ni.e. support all kind of use cases where developers need to slap on\nfooters in a quick & easy way.\n\nAnd the --exec-after option would obviously have *a lot* more use cases\nthan just squashing in ACKs.\n\nCiao,\nJohannes\n"},{"id":"283134","messageId":"20160411141428-mutt-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"alpine.DEB.2.20.1604111239100.2967@virtualbox","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-11T11:24:46Z","receivedAt":"2016-04-11T11:24:46Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, Apr 11, 2016 at 01:02:07PM +0200, Johannes Schindelin wrote:\n> Hi Michael,\n> \n> On Sun, 10 Apr 2016, Michael S. Tsirkin wrote:\n> \n> > This implements a new ack! action for git rebase -i\n> > It is essentially a middle ground between fixup! and squash!:\n> > - commits are squashed silently without editor being started\n> > - commit logs are concatenated (with action line being discarded)\n> > - because of the above, empty commits aren't discarded,\n> > their log is also included.\n> > \n> > I am using it as follows:\n> > \tgit am -s < mailbox #creates first commit\n> > \thack ...\n> > \tget mail with Ack\n> > \tgit commit --allow-empty -m `cat <<-EOF\n> > \tack! first\n> > \n> > \tAcked-by: maintainer\n> > \tEOF`\n> > \trepeat cycle\n> > \tgit rebase --autosquash -i origin/master\n> > \tbefore public branch push\n> > \n> > The \"cat\" command above is actually a script that\n> > parses the Ack mail to create the empty commit -\n> > to be submitted separately.\n> \n> This looks awfully complicated, still, and not very generic.\n> \n> How about making it easier to use, and much, much more generic, like this?\n\nI can look at using a different syntax but the below does not\nsupport the workflow I described, which is a standard\nemail based one: get email, handle it.\n\n> 1. introducing an `--add-footer` flag to `git commit` that you could use\n> like this:\n> \n> \tgit commit --amend --add-footer \"Acked-by: Bugs Bunny\"\n> 2. introducing an `--exec-after` flag to `git commit` that would be a new\n> sibling of `--fixup` and `--squash` and would work like this:\n> \n> \tgit commit --exec-after HEAD~5 \\\n> \t\t'git commit --amend --add-footer \"Acked-by: Bugs Bunny\"'\n\nBut it wouldn't address my use-case where I get an ack\nby email. If I have to dig up the relevant commit(s) by hand\nanyway, then what was the point?\n\n> \n> (it should imply `--allow-empty`, of course, and probably even fail if\n> anything was staged for commit at that point.) The commit message would\n> then look something like\n> \n> \texec-after! Fix broken breakage\n> \n> \tgit commit --amend --add-footer \"Acked-by: Bugs Bunny\"\n\nSo if I happen to fetch a branch from someone\nand rebase it, stuff gets auto-executed on my local system?\nThat looks scary. \n\n> This way would obviously benefit a lot more users.\n\nIt might benefit others who have the commit handy but it does not look\nlike it helps email based workflow.\n\n> For example, you could\n> easily say (and alias)\n> \n> \tgit commit --amend --add-footer 'Reviewed-by: Arrested Developer\"\n> \n> i.e. support all kind of use cases where developers need to slap on\n> footers in a quick & easy way.\n>\n> And the --exec-after option would obviously have *a lot* more use cases\n> than just squashing in ACKs.\n> \n> Ciao,\n> Johannes\n\nSo far I only see examples of adding footers. If that's all we can think\nup, why code in all this genericity? All these small scripts scattered\naround just make things hard to use, and add security issues.\n\n\n-- \nMSR\n"},{"id":"283135","messageId":"87lh4kic49.fsf@gmail.com","threadId":"41981","inReplyTo":"alpine.DEB.2.20.1604111239100.2967@virtualbox","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Christian Neukirchen","fromEmail":"chneukirchen@gmail.com","sentAt":"2016-04-11T12:05:58Z","receivedAt":"2016-04-11T12:05:58Z","isPatch":true,"sender":{"key":"chneukirchen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/139?v=4"},"body":"Johannes Schindelin writes:\n\n> How about making it easier to use, and much, much more generic, like this?\n>\n> 1. introducing an `--add-footer` flag to `git commit` that you could use\n> like this:\n>\n> \tgit commit --amend --add-footer \"Acked-by: Bugs Bunny\"\n\nI have a script where I currently do this ala:\n\nGIT_EDITOR=\"git -c trailer.closes.ifExists=replace interpret-trailers \\\n --trailer 'Closes: #$PR [via git-merge-pr]' --in-place\" \\\ngit commit --quiet --amend\n\nBut I think it could be a good addition to porcelain.\n(interpret-trailers still feels hard to drive by a script...)\n\n-- \nChristian Neukirchen http://chneukirchen.org\n"},{"id":"283139","messageId":"alpine.DEB.2.20.1604111736060.2967@virtualbox","threadId":"41981","inReplyTo":"20160411141428-mutt-send-email-mst@redhat.com","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-04-11T15:36:45Z","receivedAt":"2016-04-11T15:36:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Michael,\n\nOn Mon, 11 Apr 2016, Michael S. Tsirkin wrote:\n\n> So far I only see examples of adding footers. If that's all we can think\n> up, why code in all this genericity?\n\nBecause as far as I can see, the only benefitor of your patches would be\nyou.\n\nCiao,\nJohannes\n"},{"id":"283143","messageId":"20160411184535-mutt-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"alpine.DEB.2.20.1604111736060.2967@virtualbox","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-11T16:41:49Z","receivedAt":"2016-04-11T16:41:49Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"Repost, sorry about the noise.\n\nOn Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote:\n> Hi Michael,\n> \n> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote:\n> \n> > So far I only see examples of adding footers. If that's all we can think\n> > up, why code in all this genericity?\n> \n> Because as far as I can see, the only benefitor of your patches would be\n> you.\n> \n> Ciao,\n> Johannes\n\nThis seems unlikely. Just merging the patches won't benefit me directly\n- I have maintained them in my tree for a couple of years now with very\nlittle effort. For sure, I could benefit if they get merged and then\nsomeone improves them further - that was the point of posting them - but\nthen I'm not the only benefitor.\n\nThe workflow including getting acks for patches by email is not handled\nwell by upstream git right now. It would surprise me if no one uses it\nif it's upstream, as you seem to suggest. But maybe most people moved\non and just do pull requests instead.\n\n-- \nMST\n"},{"id":"283153","messageId":"xmqqlh4krkop.fsf@gitster.mtv.corp.google.com","threadId":"41981","inReplyTo":"20160411184535-mutt-send-email-mst@redhat.com","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-11T19:48:22Z","receivedAt":"2016-04-11T19:48:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n> Repost, sorry about the noise.\n>\n> On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote:\n>> Hi Michael,\n>> \n>> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote:\n>> \n>> > So far I only see examples of adding footers. If that's all we can think\n>> > up, why code in all this genericity?\n>> \n>> Because as far as I can see, the only benefitor of your patches would be\n>> you.\n>> \n>> Ciao,\n>> Johannes\n>\n> This seems unlikely. Just merging the patches won't benefit me directly\n> - I have maintained them in my tree for a couple of years now with very\n> little effort. For sure, I could benefit if they get merged and then\n> someone improves them further - that was the point of posting them - but\n> then I'm not the only benefitor.\n>\n> The workflow including getting acks for patches by email is not handled\n> well by upstream git right now. It would surprise me if no one uses it\n> if it's upstream, as you seem to suggest. But maybe most people moved\n> on and just do pull requests instead.\n\nI doubt I would use this in its current form myself.\n\nPatch series I receive are all queued on their own separate topic\nbranches, and having to switch branches only to create a fake empty\ncommit to record received Acked-by and Reviewed-by is a chore that\nserves only half of what needs to be done. Once I decide to switch\nback to the topic branch after receiving Acked-by and Reviewed-by,\nI'd rather \"rebase -i\" to directly record them at that point, with\n\"reword\".\n\nIf the \"trailers\" stuff is packaged into an easier-to-use format to\nuse with \"git commit --amend\", I may use that together with \"exec\"\nto automatically add these while doing so, but again, I do not see\nany need for fake empty commits out of received e-mails in the\nresulting workflow.\n\nThat does not at all mean nobody other than Michael would use it,\nthough.\n"},{"id":"283154","messageId":"20160411225222-mutt-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"xmqqlh4krkop.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-11T19:55:27Z","receivedAt":"2016-04-11T19:55:27Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, Apr 11, 2016 at 12:48:22PM -0700, Junio C Hamano wrote:\n> \"Michael S. Tsirkin\" writes:\n> \n> > Repost, sorry about the noise.\n> >\n> > On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote:\n> >> Hi Michael,\n> >> \n> >> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote:\n> >> \n> >> > So far I only see examples of adding footers. If that's all we can think\n> >> > up, why code in all this genericity?\n> >> \n> >> Because as far as I can see, the only benefitor of your patches would be\n> >> you.\n> >> \n> >> Ciao,\n> >> Johannes\n> >\n> > This seems unlikely. Just merging the patches won't benefit me directly\n> > - I have maintained them in my tree for a couple of years now with very\n> > little effort. For sure, I could benefit if they get merged and then\n> > someone improves them further - that was the point of posting them - but\n> > then I'm not the only benefitor.\n> >\n> > The workflow including getting acks for patches by email is not handled\n> > well by upstream git right now. It would surprise me if no one uses it\n> > if it's upstream, as you seem to suggest. But maybe most people moved\n> > on and just do pull requests instead.\n> \n> I doubt I would use this in its current form myself.\n> \n> Patch series I receive are all queued on their own separate topic\n> branches, and having to switch branches only to create a fake empty\n> commit to record received Acked-by and Reviewed-by is a chore that\n> serves only half of what needs to be done.\n\nInteresting. An empty commit would be rather easy to create on any\nbranch, not just the current one, using git-commit-tree.\nDoes it sounds interesting if I teach\ngit ack to get an active branch as a parameter?\n\n\n> Once I decide to switch\n> back to the topic branch after receiving Acked-by and Reviewed-by,\n> I'd rather \"rebase -i\" to directly record them at that point, with\n> \"reword\".\n> \n> If the \"trailers\" stuff is packaged into an easier-to-use format to\n> use with \"git commit --amend\", I may use that together with \"exec\"\n> to automatically add these while doing so, but again, I do not see\n> any need for fake empty commits out of received e-mails in the\n> resulting workflow.\n> \n> That does not at all mean nobody other than Michael would use it,\n> though.\n"},{"id":"283155","messageId":"vpqr3ebnc9w.fsf@anie.imag.fr","threadId":"41981","inReplyTo":"20160411225222-mutt-send-email-mst@redhat.com","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-04-11T20:03:39Z","receivedAt":"2016-04-11T20:03:39Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Michael S. Tsirkin\" writes:\n\n> On Mon, Apr 11, 2016 at 12:48:22PM -0700, Junio C Hamano wrote:\n>> \"Michael S. Tsirkin\" writes:\n>> \n>> > Repost, sorry about the noise.\n>> >\n>> > On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote:\n>> >> Hi Michael,\n>> >> \n>> >> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote:\n>> >> \n>> >> > So far I only see examples of adding footers. If that's all we can think\n>> >> > up, why code in all this genericity?\n>> >> \n>> >> Because as far as I can see, the only benefitor of your patches would be\n>> >> you.\n>> >> \n>> >> Ciao,\n>> >> Johannes\n>> >\n>> > This seems unlikely. Just merging the patches won't benefit me directly\n>> > - I have maintained them in my tree for a couple of years now with very\n>> > little effort. For sure, I could benefit if they get merged and then\n>> > someone improves them further - that was the point of posting them - but\n>> > then I'm not the only benefitor.\n>> >\n>> > The workflow including getting acks for patches by email is not handled\n>> > well by upstream git right now. It would surprise me if no one uses it\n>> > if it's upstream, as you seem to suggest. But maybe most people moved\n>> > on and just do pull requests instead.\n>> \n>> I doubt I would use this in its current form myself.\n>> \n>> Patch series I receive are all queued on their own separate topic\n>> branches, and having to switch branches only to create a fake empty\n>> commit to record received Acked-by and Reviewed-by is a chore that\n>> serves only half of what needs to be done.\n>\n> Interesting. An empty commit would be rather easy to create on any\n> branch, not just the current one, using git-commit-tree.\n\nThis \"modify a branch without checking-it out\" makes me think of \"git\nnotes\". It may make sense to teach \"git rebase -i\" to look for notes in\nrebased commits and append them to the commit message when applying.\nJust an idea, not necessarily a good one ;-).\n\n> Does it sounds interesting if I teach\n> git ack to get an active branch as a parameter?\n\nI think \"ack\" is not a good name for this feature: you use it to append\n\"Acked-by\", but it can be used to append any trailer (for example,\nReviewed-by: would make complete sense too). I think using a better name\nwould help the discussion (to remove the \"it's my use-case\" biais).\nPerhaps \"append\"?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"283172","messageId":"20160412104133-mutt-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"vpqr3ebnc9w.fsf@anie.imag.fr","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-12T07:51:02Z","receivedAt":"2016-04-12T07:51:02Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, Apr 11, 2016 at 10:03:39PM +0200, Matthieu Moy wrote:\n> \"Michael S. Tsirkin\" writes:\n> \n> > On Mon, Apr 11, 2016 at 12:48:22PM -0700, Junio C Hamano wrote:\n> >> \"Michael S. Tsirkin\" writes:\n> >> \n> >> > Repost, sorry about the noise.\n> >> >\n> >> > On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote:\n> >> >> Hi Michael,\n> >> >> \n> >> >> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote:\n> >> >> \n> >> >> > So far I only see examples of adding footers. If that's all we can think\n> >> >> > up, why code in all this genericity?\n> >> >> \n> >> >> Because as far as I can see, the only benefitor of your patches would be\n> >> >> you.\n> >> >> \n> >> >> Ciao,\n> >> >> Johannes\n> >> >\n> >> > This seems unlikely. Just merging the patches won't benefit me directly\n> >> > - I have maintained them in my tree for a couple of years now with very\n> >> > little effort. For sure, I could benefit if they get merged and then\n> >> > someone improves them further - that was the point of posting them - but\n> >> > then I'm not the only benefitor.\n> >> >\n> >> > The workflow including getting acks for patches by email is not handled\n> >> > well by upstream git right now. It would surprise me if no one uses it\n> >> > if it's upstream, as you seem to suggest. But maybe most people moved\n> >> > on and just do pull requests instead.\n> >> \n> >> I doubt I would use this in its current form myself.\n> >> \n> >> Patch series I receive are all queued on their own separate topic\n> >> branches, and having to switch branches only to create a fake empty\n> >> commit to record received Acked-by and Reviewed-by is a chore that\n> >> serves only half of what needs to be done.\n> >\n> > Interesting. An empty commit would be rather easy to create on any\n> > branch, not just the current one, using git-commit-tree.\n> \n> This \"modify a branch without checking-it out\" makes me think of \"git\n> notes\". It may make sense to teach \"git rebase -i\" to look for notes in\n> rebased commits and append them to the commit message when applying.\n> Just an idea, not necessarily a good one ;-).\n\nTwo things making it harder\n\t- machinery to look for commits is part of git rebase anyway\n\t- notes are expected to come after --- at the moment\n\n\n> > Does it sounds interesting if I teach\n> > git ack to get an active branch as a parameter?\n> \n> I think \"ack\" is not a good name for this feature: you use it to append\n> \"Acked-by\", but it can be used to append any trailer (for example,\n> Reviewed-by: would make complete sense too).\n\nYes - I use it to append all trailers.\n\n> I think using a better name\n> would help the discussion (to remove the \"it's my use-case\" biais).\n> Perhaps \"append\"?\n\nOr \"trailer\".\n\n> -- \n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n"},{"id":"283196","messageId":"xmqqd1pustdp.fsf@gitster.mtv.corp.google.com","threadId":"41981","inReplyTo":"vpqr3ebnc9w.fsf@anie.imag.fr","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-12T16:07:30Z","receivedAt":"2016-04-12T16:07:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> \"Michael S. Tsirkin\" writes:\n>\n>> Interesting. An empty commit would be rather easy to create on any\n>> branch, not just the current one, using git-commit-tree.\n>\n> This \"modify a branch without checking-it out\" makes me think of \"git\n> notes\". It may make sense to teach \"git rebase -i\" to look for notes in\n> rebased commits and append them to the commit message when applying.\n> Just an idea, not necessarily a good one ;-).\n\nYeah that may actually fly well, as a note is designed to attach to\nan exact commit, not to a branch, so that feels more natural.\n\nAs to the \"use commit-tree\", well, personally I am not interested in\na solution that can work well in my workflow ONLY if I further script\nit. That's half-solution and unless that half is done very well,\nI'd rather do a full solution better.\n\n\tNote: this is a continuation of \"I personally would not use\n\tit, even though other people might\" discussion.\n\nI was also wondering if I should just script around filter-branch,\nif all I am futzing with is the data in the trailer block, doing the\nmunging of the trailer block with interpret-trailers, naturally.\n\nIn any case, a recent occasion that I had to do something related to\nthis topic may illustrate the boundary of requirements:\n\n Two developers, Michael and David, are involved. David sends a\n 24-patch series, some of which were written by Michael and\n others by David. The in-body \"From:\" lines are set right and\n the resulting patches record authorship correctly.\n\n Michael reminds David that patches authored by Michael still\n need to be signed-off by David. David sends a single message\n \"those by Michael in this series are signed off by me\".\n\n Michael also says that he reviewed all patches authored by\n David, i.e. \"Add Acked-by Michael to all patches in this series\n authored by David\".\n\nNow this is an extreme case where a simple \"OK I received an\ne-mailed Ack, so I can rely on the subject line matching to mark it\nto be squashed\" approach will never work (i.e. if we were automating\nit I'd expect that the script in DSL to the automation machinery to\ntake at last as many (conceptual) bits as the above problem\ndescription).\n"},{"id":"283200","messageId":"20160412190904-mutt-send-email-mst@redhat.com","threadId":"41981","inReplyTo":"xmqqd1pustdp.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-12T16:33:50Z","receivedAt":"2016-04-12T16:33:50Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Apr 12, 2016 at 09:07:30AM -0700, Junio C Hamano wrote:\n> Matthieu Moy writes:\n> \n> > \"Michael S. Tsirkin\" writes:\n> >\n> >> Interesting. An empty commit would be rather easy to create on any\n> >> branch, not just the current one, using git-commit-tree.\n> >\n> > This \"modify a branch without checking-it out\" makes me think of \"git\n> > notes\". It may make sense to teach \"git rebase -i\" to look for notes in\n> > rebased commits and append them to the commit message when applying.\n> > Just an idea, not necessarily a good one ;-).\n> \n> Yeah that may actually fly well, as a note is designed to attach to\n> an exact commit, not to a branch, so that feels more natural.\n\nWe'd have to invent a way to show that in the rebase -i output though.\n\n\n> As to the \"use commit-tree\", well, personally I am not interested in\n> a solution that can work well in my workflow ONLY if I further script\n> it. That's half-solution and unless that half is done very well,\n> I'd rather do a full solution better.\n\nAbsolutely. But that's not what I meant. I will add a flag to git-ack to\nselect a branch and use commit-tree to put the ack commit there\n*internally*. Would this do everything you need? How do you select\na branch? Automatically or do you remember the mapping from topic\nto branch name?\n\n> \tNote: this is a continuation of \"I personally would not use\n> \tit, even though other people might\" discussion.\n> \n> I was also wondering if I should just script around filter-branch,\n> if all I am futzing with is the data in the trailer block, doing the\n> munging of the trailer block with interpret-trailers, naturally.\n> \n> In any case, a recent occasion that I had to do something related to\n> this topic may illustrate the boundary of requirements:\n> \n> Two developers, Michael and David, are involved. David sends a\n> 24-patch series, some of which were written by Michael and\n> others by David. The in-body \"From:\" lines are set right and\n> the resulting patches record authorship correctly.\n> \n> Michael reminds David that patches authored by Michael still\n> need to be signed-off by David. David sends a single message\n> \"those by Michael in this series are signed off by me\".\n> \n> Michael also says that he reviewed all patches authored by\n> David, i.e. \"Add Acked-by Michael to all patches in this series\n> authored by David\".\n> \n> Now this is an extreme case where a simple \"OK I received an\n> e-mailed Ack, so I can rely on the subject line matching to mark it\n> to be squashed\" approach will never work (i.e. if we were automating\n> it I'd expect that the script in DSL to the automation machinery to\n> take at last as many (conceptual) bits as the above problem\n> description).\n\nSo here's how I solve the second part for now - that\nis very common: I expect Michael to write something like\nFor series:\nAcked-by: Michael S. Tsirkin \n\nthen I run git ack -s to put the signature in a file .git/ACKS.\n\n(git ack -s is just writing acks into .git/ACKS so\nif the email format is wrong I just edit it manually).\n\nAnd then I tag the series in email and run git ack -r to\nadd the ack tag.\n\nFor first part, that is less common but also happens\n(for example I get \"for patches 1,7 and 23 in series: ACK\") -\nI would do git ack -s\nto store David's signoff, then tag just messages by David\n(probably just using limit ~b From:\\ David in mutt)\nand pipe them to git ack -r.\n\nDoes this sound user-friendly enough? What would you do\ndifferently?\n\n-- \nMST\n"},{"id":"283214","messageId":"xmqqy48ippgm.fsf@gitster.mtv.corp.google.com","threadId":"41981","inReplyTo":"20160412190904-mutt-send-email-mst@redhat.com","subject":"Re: [PATCH 1/4] rebase -i: add ack action","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-12T20:00:25Z","receivedAt":"2016-04-12T20:00:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n>> As to the \"use commit-tree\", well, personally I am not interested in\n>> a solution that can work well in my workflow ONLY if I further script\n>> it. That's half-solution and unless that half is done very well,\n>> I'd rather do a full solution better.\n>\n> Absolutely. But that's not what I meant. I will add a flag to git-ack to\n> select a branch and use commit-tree to put the ack commit there\n> *internally*. Would this do everything you need? How do you select\n> a branch? Automatically or do you remember the mapping from topic\n> to branch name?\n> ...\n> For first part, that is less common but also happens\n> (for example I get \"for patches 1,7 and 23 in series: ACK\") -\n> I would do git ack -s\n> to store David's signoff, then tag just messages by David\n> (probably just using limit ~b From:\\ David in mutt)\n> and pipe them to git ack -r.\n>\n> Does this sound user-friendly enough? What would you do\n> differently?\n\nBecause my workflow is I usually comment on and review many topics\nwithout applying them to anywhere, by the time I start applying\npatches, I often know which one got Acked and Reviewed already.\n\nSo for them the workflow would be\n\n 0. Think which maintenance track the topic should be based on.\n\n 1. Fork\n\n $ git checkout -b maint-\n\n 2. In my MUA, pipe the message into this pipeline\n\n Meta/add-by -r peff@ -a Tsirkin | git am -s3c\n\nwhere the \"add-by\" script (found in 'todo') expands the given names\nusing .mailmap and appends appropriate trailers (the latter should\neventually be updated to use interpret-trailers when the tool\nmatures, but I did not think it was there yet when I last updated\nthe \"add-by\" script).\n\nSo for a use case where I work off of my MUA, I have no use for your\n\"git ack\".\n"}]}