{"thread":{"id":"36899","subject":"[PATCH RFC] git-am: support any number of signatures","startedAt":"2014-06-12T16:12:35Z","lastAt":"2014-10-14T05:29:11Z","messageCount":31,"participants":["Michael S. Tsirkin","Junio C Hamano","René Scharfe","Christian Couder","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"243950","messageId":"1402589505-27632-1-git-send-email-mst@redhat.com","threadId":"36899","inReplyTo":null,"subject":"[PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-06-12T16:12:35Z","receivedAt":"2014-06-12T16:12:35Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"I'm using different signature tags for git am depending on the patch,\nproject and other factors.\n\nSometimes I add multiple tags as well, e.g. QEMU\nwants both Reviewed-by and Signed-off-by tags.\n\nThis patch makes it easy to do so:\n1. new parameter am.signoff can be used any number\n\tof times:\n\n[am]\n\tsignoff = \"Reviewed-by: Michael S. Tsirkin \"\n\tsignoff = \"Signed-off-by: Michael S. Tsirkin \"\n\n\tif set all signatures are picked up when git am -s is used.\n\n2. Any number of alternative signatures\n\n[am \"a\"]\n\tsignoff = \"Acked-by: Michael S. Tsirkin \"\n\n\tif set the signature type can be specified by passing\n\ta parameter to the -s flag:\n\n\tgit am -sa\n\nNo docs or tests, sorry, so not yet ready for master, but I'm using this\nall the time without any issues so maybe ok for pu.\nEarly flames/feedback/help welcome.\n\nSigned-off-by: Michael S. Tsirkin \n---\n git-am.sh | 36 ++++++++++++++++++++++++++++--------\n 1 file changed, 28 insertions(+), 8 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex ee61a77..e992c34 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -13,7 +13,7 @@ i,interactive run interactively\n b,binary* (historical option -- no-op)\n 3,3way allow fall back on 3way merging if needed\n q,quiet be quiet\n-s,signoff add a Signed-off-by line to the commit message\n+s,signoff? add a Signed-off-by line to the commit message\n u,utf8 recode into utf8 (default)\n k,keep pass -k flag to git-mailinfo\n keep-non-patch pass -b flag to git-mailinfo\n@@ -136,7 +136,7 @@ fall_back_3way () {\n eval \"$cmd\" &&\n GIT_INDEX_FILE=\"$dotest/patch-merge-tmp-index\" \\\n git write-tree >\"$dotest/patch-merge-base+\" ||\n- cannot_fallback \"$(gettext \"Repository lacks necessary blobs to fall back on 3-way merge.\")\"\n+ cannot_fallback \"$(gettext \"Repository lsignoffs necessary blobs to fall back on 3-way merge.\")\"\n \n say \"$(gettext \"Using index info to reconstruct a base tree...\")\"\n \n@@ -383,6 +383,7 @@ then\n keepcr=t\n fi\n \n+signoffs=\n while test $# != 0\n do\n \tcase \"$1\" in\n@@ -394,8 +395,15 @@ it will be removed. Please do not use it anymore.\"\n \t\t;;\n \t-3|--3way)\n \t\tthreeway=t ;;\n-\t-s|--signoff)\n-\t\tsign=t ;;\n+\t--signoff)\n+\t\tsign=t\n+\t\ts=$(git config --get-all am.signoff)\n+\t\tsignoffs=(\"${signoffs[@]}\" \"${s[@]}\") ;;\n+\t--signoff=*)\n+\t\tsign=t\n+\t\ta=\"${1#--signoff=}\"\n+\t\ts=$(git config --get-all am.\"${a}\".signoff)\n+\t\tsignoffs=(\"${signoffs[@]}\" \"${s[@]}\") ;;\n \t-u|--utf8)\n \t\tutf8=t ;; # this is now default\n \t--no-utf8)\n@@ -644,14 +652,25 @@ fi\n git_apply_opt=$(cat \"$dotest/apply-opt\")\n if test \"$(cat \"$dotest/sign\")\" = t\n then\n-\tSIGNOFF=$(git var GIT_COMMITTER_IDENT | sed -e '\n-\t\t\ts/>.*/>/\n-\t\t\ts/^/Signed-off-by: /'\n-\t\t)\n+\tfor ack in \"${signoffs[@]}\"; do\n+\t\tif test \"$SIGNOFF\"\n+\t\tthen\n+\t\t\tSIGNOFF=\"$SIGNOFF\\n$ack\"\n+\t\telse\n+\t\t\tSIGNOFF=\"$ack\"\n+\t\tfi\n+\tdone\n+\tif test -z \"$SIGNOFF\"\n+\tthen\n+\t\tSIGNOFF=$(git var GIT_COMMITTER_IDENT | sed -e '\n+\t\t\t\ts/>.*/>/\n+\t\t\t\ts/^/Signed-off-by: /'\n+\t\t\t)\n+\tfi\n else\n \tSIGNOFF=\n fi\n \n last=$(cat \"$dotest/last\")\n this=$(cat \"$dotest/next\")\n if test \"$skip\" = t\n-- \nMST\n"},{"id":"244018","messageId":"xmqqioo654mg.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"1402589505-27632-1-git-send-email-mst@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-12T19:07:03Z","receivedAt":"2014-06-12T19:07:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n> I'm using different signature tags for git am depending on the patch,\n> project and other factors.\n>\n> Sometimes I add multiple tags as well, e.g. QEMU\n> wants both Reviewed-by and Signed-off-by tags.\n>\n> This patch makes it easy to do so:\n> 1. new parameter am.signoff can be used any number\n> \tof times:\n>\n> [am]\n> \tsignoff = \"Reviewed-by: Michael S. Tsirkin \"\n> \tsignoff = \"Signed-off-by: Michael S. Tsirkin \"\n>\n> \tif set all signatures are picked up when git am -s is used.\n\nHow does this interact with the logic to avoid appending the same\nSigned-off-by: line as the last one the incoming message already\nhas?\n\n> 2. Any number of alternative signatures\n>\n> [am \"a\"]\n> \tsignoff = \"Acked-by: Michael S. Tsirkin \"\n>\n> \tif set the signature type can be specified by passing\n> \ta parameter to the -s flag:\n>\n> \tgit am -sa\n>\n> No docs or tests, sorry, so not yet ready for master, but I'm using this\n> all the time without any issues so maybe ok for pu.\n> Early flames/feedback/help welcome.\n\nHow does that \"a\" in [am \"a\"] work? If it defines some kind of\nscope (i.e. use am.a.* instead of am.* when I specify I am using \"a\"\nset somehow), that might be something interesting, but if it applies\nonly to sign-off and other things, then I am not sure if I like it,\nas that would invite confusions from end users.\n\n> +\t\tsignoffs=(\"${signoffs[@]}\" \"${s[@]}\") ;;\n\nIs this a shell array? It won't fly in our codebase if that is the\ncase.\n"},{"id":"244021","messageId":"5399FEC2.3020309@web.de","threadId":"36899","inReplyTo":"1402589505-27632-1-git-send-email-mst@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2014-06-12T19:25:54Z","receivedAt":"2014-06-12T19:25:54Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 12.06.2014 18:12, schrieb Michael S. Tsirkin:\n> @@ -136,7 +136,7 @@ fall_back_3way () {\n> eval \"$cmd\" &&\n> GIT_INDEX_FILE=\"$dotest/patch-merge-tmp-index\" \\\n> git write-tree >\"$dotest/patch-merge-base+\" ||\n> - cannot_fallback \"$(gettext \"Repository lacks necessary blobs to fall back on 3-way merge.\")\"\n> + cannot_fallback \"$(gettext \"Repository lsignoffs necessary blobs to fall back on 3-way merge.\")\"\n\nlsignoffs?\n"},{"id":"244069","messageId":"20140613080036.GA2117@redhat.com","threadId":"36899","inReplyTo":"xmqqioo654mg.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-06-13T08:00:36Z","receivedAt":"2014-06-13T08:00:36Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Thu, Jun 12, 2014 at 12:07:03PM -0700, Junio C Hamano wrote:\n> \"Michael S. Tsirkin\" writes:\n> \n> > I'm using different signature tags for git am depending on the patch,\n> > project and other factors.\n> >\n> > Sometimes I add multiple tags as well, e.g. QEMU\n> > wants both Reviewed-by and Signed-off-by tags.\n> >\n> > This patch makes it easy to do so:\n> > 1. new parameter am.signoff can be used any number\n> > \tof times:\n> >\n> > [am]\n> > \tsignoff = \"Reviewed-by: Michael S. Tsirkin \"\n> > \tsignoff = \"Signed-off-by: Michael S. Tsirkin \"\n> >\n> > \tif set all signatures are picked up when git am -s is used.\n> \n> How does this interact with the logic to avoid appending the same\n> Signed-off-by: line as the last one the incoming message already\n> has?\n\nNot handled if you have multiple signatures.\nThat will have to be fixed.\nDo we only care about the last line?\n\nSigned-off-by: A\nSigned-off-by: B\n\ndo we want to add\n\nSigned-off-by: A\n\nor would it be better to replace with\nSigned-off-by: B\nSigned-off-by: A\n\n?\n\nCurrent git am will add A twice, I wonder if this is\na feature or a bug.\n\n> > 2. Any number of alternative signatures\n> >\n> > [am \"a\"]\n> > \tsignoff = \"Acked-by: Michael S. Tsirkin \"\n> >\n> > \tif set the signature type can be specified by passing\n> > \ta parameter to the -s flag:\n> >\n> > \tgit am -sa\n> >\n> > No docs or tests, sorry, so not yet ready for master, but I'm using this\n> > all the time without any issues so maybe ok for pu.\n> > Early flames/feedback/help welcome.\n> \n> How does that \"a\" in [am \"a\"] work? If it defines some kind of\n> scope (i.e. use am.a.* instead of am.* when I specify I am using \"a\"\n> set somehow), that might be something interesting, but if it applies\n> only to sign-off and other things, then I am not sure if I like it,\n> as that would invite confusions from end users.\n> \n> > +\t\tsignoffs=(\"${signoffs[@]}\" \"${s[@]}\") ;;\n> \n> Is this a shell array? It won't fly in our codebase if that is the\n> case.\n"},{"id":"244070","messageId":"20140613080118.GB2117@redhat.com","threadId":"36899","inReplyTo":"5399FEC2.3020309@web.de","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-06-13T08:01:18Z","receivedAt":"2014-06-13T08:01:18Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Thu, Jun 12, 2014 at 09:25:54PM +0200, René Scharfe wrote:\n> Am 12.06.2014 18:12, schrieb Michael S. Tsirkin:\n> >@@ -136,7 +136,7 @@ fall_back_3way () {\n> > eval \"$cmd\" &&\n> > GIT_INDEX_FILE=\"$dotest/patch-merge-tmp-index\" \\\n> > git write-tree >\"$dotest/patch-merge-base+\" ||\n> >- cannot_fallback \"$(gettext \"Repository lacks necessary blobs to fall back on 3-way merge.\")\"\n> >+ cannot_fallback \"$(gettext \"Repository lsignoffs necessary blobs to fall back on 3-way merge.\")\"\n> \n> lsignoffs?\n\nHeh good catch, I'll fix this up.\nThanks!\n"},{"id":"244154","messageId":"xmqqy4x03ecm.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"20140613080036.GA2117@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-13T17:32:09Z","receivedAt":"2014-06-13T17:32:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n> On Thu, Jun 12, 2014 at 12:07:03PM -0700, Junio C Hamano wrote:\n>> \"Michael S. Tsirkin\" writes:\n>> ...\n>> > 1. new parameter am.signoff can be used any number\n>> > \tof times:\n>> >\n>> > [am]\n>> > \tsignoff = \"Reviewed-by: Michael S. Tsirkin \"\n>> > \tsignoff = \"Signed-off-by: Michael S. Tsirkin \"\n>> >\n>> > \tif set all signatures are picked up when git am -s is used.\n>> \n>> How does this interact with the logic to avoid appending the same\n>> Signed-off-by: line as the last one the incoming message already\n>> has?\n>\n> Not handled if you have multiple signatures.\n> That will have to be fixed.\n> Do we only care about the last line?\n>\n> Signed-off-by: A\n> Signed-off-by: B\n>\n> do we want to add\n>\n> Signed-off-by: A\n>\n> or would it be better to replace with\n> Signed-off-by: B\n> Signed-off-by: A\n>\n> ?\n>\n> Current git am will add A twice, I wonder if this is\n> a feature or a bug.\n\nThis is very much deliberate.\n\nAppending A after existing A and B is meant to record that the patch\noriginated from A, passed thru B possibly with changes by B, came\nback to A who wants to assert that the result is still under DCO.\n\nThe only case we can safely omit appending A's sign-off is when the\nlast one in the chain is by A. Imagine that you had a patch signed\noff by B, which A may have tweaked and forwarded under DCO with A's\nsign-off. Such a patch would have sign-off chain B-A.\n\nNow A makes further changes to the patch and says \"the further\nchange is also something I am authorized to release as open source\"\nwith the \"-s\" option or some other way. It would not change that A\ncan contribute under DCO if we did not add an extra A after existing\nB-A sign-off chain in that case.\n"},{"id":"244209","messageId":"20140615102736.GA11798@redhat.com","threadId":"36899","inReplyTo":"xmqqy4x03ecm.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-06-15T10:27:36Z","receivedAt":"2014-06-15T10:27:36Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Fri, Jun 13, 2014 at 10:32:09AM -0700, Junio C Hamano wrote:\n> \"Michael S. Tsirkin\" writes:\n> \n> > On Thu, Jun 12, 2014 at 12:07:03PM -0700, Junio C Hamano wrote:\n> >> \"Michael S. Tsirkin\" writes:\n> >> ...\n> >> > 1. new parameter am.signoff can be used any number\n> >> > \tof times:\n> >> >\n> >> > [am]\n> >> > \tsignoff = \"Reviewed-by: Michael S. Tsirkin \"\n> >> > \tsignoff = \"Signed-off-by: Michael S. Tsirkin \"\n> >> >\n> >> > \tif set all signatures are picked up when git am -s is used.\n> >> \n> >> How does this interact with the logic to avoid appending the same\n> >> Signed-off-by: line as the last one the incoming message already\n> >> has?\n> >\n> > Not handled if you have multiple signatures.\n> > That will have to be fixed.\n> > Do we only care about the last line?\n> >\n> > Signed-off-by: A\n> > Signed-off-by: B\n> >\n> > do we want to add\n> >\n> > Signed-off-by: A\n> >\n> > or would it be better to replace with\n> > Signed-off-by: B\n> > Signed-off-by: A\n> >\n> > ?\n> >\n> > Current git am will add A twice, I wonder if this is\n> > a feature or a bug.\n> \n> This is very much deliberate.\n> \n> Appending A after existing A and B is meant to record that the patch\n> originated from A, passed thru B possibly with changes by B, came\n> back to A who wants to assert that the result is still under DCO.\n> \n> The only case we can safely omit appending A's sign-off is when the\n> last one in the chain is by A. Imagine that you had a patch signed\n> off by B, which A may have tweaked and forwarded under DCO with A's\n> sign-off. Such a patch would have sign-off chain B-A.\n> \n> Now A makes further changes to the patch and says \"the further\n> change is also something I am authorized to release as open source\"\n> with the \"-s\" option or some other way. It would not change that A\n> can contribute under DCO if we did not add an extra A after existing\n> B-A sign-off chain in that case.\n\nOK imagine we have signatures:\nA\nB\n\nNow A wants to sign this patch.\n\nI think there are two reasonable ways to behave:\n1. What you describe above:\nA\nB\nA\n\n2. For things like Tested-by: tags, removing tag from\nwhere it was and adding it at the bottom:\n\nB\nA\n\n\nThis probably calls for a separate feature:\nmaybe adding \"acks\" along with \"signoffs\"?\nacks would be unique, re-adding ack removes it from\nthe message and adds at the bottom.\n\n-- \nMST\n"},{"id":"244293","messageId":"xmqqy4wwraoz.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"20140615102736.GA11798@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-16T18:06:20Z","receivedAt":"2014-06-16T18:06:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n> Now A wants to sign this patch.\n>\n> I think there are two reasonable ways to behave:\n> 1. What you describe above:\n> A\n> B\n> A\n\nThat is the only sensible thing to do for Signed-off-by footers.\n\n> 2. For things like Tested-by: tags, removing tag from\n> where it was and adding it at the bottom:\n>\n> B\n> A\n\nYou can make it arbitrarily more complex. A sends with sign-off, B\ntweaks and tests *that* version and forwards with sign-off, A\nfurther tweaks, which may invalidate the earlier tests, so A asks B\nto retest and then forward it to Linus when everything checks out.\n\nWhat should the end result look like?\n\n\tSoB: A\n\tSoB: B\n Tested-by: B\n SoB: A\n Tested-by: B\n\tSoB: B\n\nperhaps?\n\n> This probably calls for a separate feature:\n> maybe adding \"acks\" along with \"signoffs\"?\n> acks would be unique, re-adding ack removes it from\n> the message and adds at the bottom.\n\nThis kind of complication is mostly up to the policies of the\nprojects that are users of Git, and not something we as the Git\nproject want to set in stone inside \"git am\" implementation.\n\nPerhaps consult what has been discussed on Christian's \"trailer\"\nseries in the list archive and then think about how to integrate /\nmake use of it inside \"am\"?\n"},{"id":"244497","messageId":"20140618030903.GA19593@redhat.com","threadId":"36899","inReplyTo":"xmqqy4wwraoz.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-06-18T03:09:03Z","receivedAt":"2014-06-18T03:09:03Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, Jun 16, 2014 at 11:06:20AM -0700, Junio C Hamano wrote:\n> \"Michael S. Tsirkin\" writes:\n> \n> > Now A wants to sign this patch.\n> >\n> > I think there are two reasonable ways to behave:\n> > 1. What you describe above:\n> > A\n> > B\n> > A\n> \n> That is the only sensible thing to do for Signed-off-by footers.\n\nOK, after looking into this for a while, I realize\nthis is a special property of the Signed-off-by footer.\nFor now I think it's reasonable to just avoid de-duplicating\nother footers if any. Agree?\n\nTo have it apply to other footers, will have to implement\n^[A-Z]*-by: logic that I have implemented for sendemail, in am as well.\nI'll get back to that, but I think it's separate from this feature.\n\n-- \nMST\n"},{"id":"244501","messageId":"CAPc5daVTZynCKMubZmreAjBh3i51wPaAA+8vSRwB9dGrrJb6FA@mail.gmail.com","threadId":"36899","inReplyTo":"20140618030903.GA19593@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-18T06:49:11Z","receivedAt":"2014-06-18T06:49:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin wrote:\n>\n> OK, after looking into this for a while, I realize\n> this is a special property of the Signed-off-by footer.\n> For now I think it's reasonable to just avoid de-duplicating\n> other footers if any. Agree?\n\nNot really. I'd rather see \"git am\" hardcode as little such policy as possible.\nWe do need to support S-o-b footer and the policy we defined for it long time\nago, if only for backward compatiblity, but for any other footers,\npolicy decision\nsuch as \"dedup by default\" isn't something \"am\" should know about.\n"},{"id":"244502","messageId":"20140618073348.GA22670@redhat.com","threadId":"36899","inReplyTo":"CAPc5daVTZynCKMubZmreAjBh3i51wPaAA+8vSRwB9dGrrJb6FA@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-06-18T07:33:48Z","receivedAt":"2014-06-18T07:33:48Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Jun 17, 2014 at 11:49:11PM -0700, Junio C Hamano wrote:\n> On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin wrote:\n> >\n> > OK, after looking into this for a while, I realize\n> > this is a special property of the Signed-off-by footer.\n> > For now I think it's reasonable to just avoid de-duplicating\n> > other footers if any. Agree?\n> \n> Not really. I'd rather see \"git am\" hardcode as little such policy as possible.\n> We do need to support S-o-b footer and the policy we defined for it long time\n> ago, if only for backward compatiblity, but for any other footers,\n> policy decision\n> such as \"dedup by default\" isn't something \"am\" should know about.\n\nOK happily that's exactly what v2 that I just posted does.\nDefault S-o-b footer gets the existing policy.\nAny other footers are added on top without any tricky\ndeduplication.\n\n\n-- \nMST\n"},{"id":"244546","messageId":"xmqq38f2jed3.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"CAPc5daVTZynCKMubZmreAjBh3i51wPaAA+8vSRwB9dGrrJb6FA@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-06-18T17:51:04Z","receivedAt":"2014-06-18T17:51:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin wrote:\n>>\n>> OK, after looking into this for a while, I realize\n>> this is a special property of the Signed-off-by footer.\n>> For now I think it's reasonable to just avoid de-duplicating\n>> other footers if any. Agree?\n>\n> Not really. I'd rather see \"git am\" hardcode as little such policy as possible.\n> We do need to support S-o-b footer and the policy we defined for it long time\n> ago, if only for backward compatiblity, but for any other footers,\n> policy decision\n> such as \"dedup by default\" isn't something \"am\" should know about.\n\nBy the way, \"append without looking for dups\" is a policy decision\nthat is as bad to have as \"append with dedup\".\n\nI'd rather not to see \"am.signoff\", or any name that implies what\nthe \"-s\" option to the command is about for that matter, to be used\nin futzing with the trailers other than S-o-b in any way. As I\nunderstand it, our longer term goal is to defer that task, including\nthe user-programmable policy decisions, to something like the\n'trailer' Christian started.\n\nI suspect that it may add unnecessary work later if we overloaded\n\"signoff\" with a similar feature with the change under discussion.\nI would feel safer to see it outlined how we envision to transition\nto a more generic 'trailer' solution later if we were to enhance\n\"am\" with \"am.signoff\" now.\n\nThanks.\n"},{"id":"244548","messageId":"20140618182342.GA6988@redhat.com","threadId":"36899","inReplyTo":"xmqq38f2jed3.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-06-18T18:23:42Z","receivedAt":"2014-06-18T18:23:42Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Jun 18, 2014 at 10:51:04AM -0700, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin wrote:\n> >>\n> >> OK, after looking into this for a while, I realize\n> >> this is a special property of the Signed-off-by footer.\n> >> For now I think it's reasonable to just avoid de-duplicating\n> >> other footers if any. Agree?\n> >\n> > Not really. I'd rather see \"git am\" hardcode as little such policy as possible.\n> > We do need to support S-o-b footer and the policy we defined for it long time\n> > ago, if only for backward compatiblity, but for any other footers,\n> > policy decision\n> > such as \"dedup by default\" isn't something \"am\" should know about.\n> \n> By the way, \"append without looking for dups\" is a policy decision\n> that is as bad to have as \"append with dedup\".\n> \n> I'd rather not to see \"am.signoff\", or any name that implies what\n> the \"-s\" option to the command is about for that matter, to be used\n> in futzing with the trailers other than S-o-b in any way. As I\n> understand it, our longer term goal is to defer that task, including\n> the user-programmable policy decisions, to something like the\n> 'trailer' Christian started.\n> \n> I suspect that it may add unnecessary work later if we overloaded\n> \"signoff\" with a similar feature with the change under discussion.\n> I would feel safer to see it outlined how we envision to transition\n> to a more generic 'trailer' solution later if we were to enhance\n> \"am\" with \"am.signoff\" now.\n> \n> Thanks.\n\nI'll need to look at trailers, if indeed they are a superset of this\nfunctionality, I will transition to trailers when they land on master.\nIn this case seems easier for me to keep this out tree patch for now,\nGood thing I didn't spend time writing docs and tests :)\n\n-- \nMST\n"},{"id":"249734","messageId":"20140922140144.GA9769@redhat.com","threadId":"36899","inReplyTo":"xmqq38f2jed3.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-09-22T14:01:44Z","receivedAt":"2014-09-22T14:01:44Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Jun 18, 2014 at 10:51:04AM -0700, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin wrote:\n> >>\n> >> OK, after looking into this for a while, I realize\n> >> this is a special property of the Signed-off-by footer.\n> >> For now I think it's reasonable to just avoid de-duplicating\n> >> other footers if any. Agree?\n> >\n> > Not really. I'd rather see \"git am\" hardcode as little such policy as possible.\n> > We do need to support S-o-b footer and the policy we defined for it long time\n> > ago, if only for backward compatiblity, but for any other footers,\n> > policy decision\n> > such as \"dedup by default\" isn't something \"am\" should know about.\n> \n> By the way, \"append without looking for dups\" is a policy decision\n> that is as bad to have as \"append with dedup\".\n> \n> I'd rather not to see \"am.signoff\", or any name that implies what\n> the \"-s\" option to the command is about for that matter, to be used\n> in futzing with the trailers other than S-o-b in any way. As I\n> understand it, our longer term goal is to defer that task, including\n> the user-programmable policy decisions, to something like the\n> 'trailer' Christian started.\n> \n> I suspect that it may add unnecessary work later if we overloaded\n> \"signoff\" with a similar feature with the change under discussion.\n> I would feel safer to see it outlined how we envision to transition\n> to a more generic 'trailer' solution later if we were to enhance\n> \"am\" with \"am.signoff\" now.\n> \n> Thanks.\n\nHi Junio, Christian,\nit's been a while.\nI see that the work on trailers is going on.\nI tried going over the documentation but I could not figure\nout how would one implement multiple signatures using the\ntrailers mechanism.\n\nAs a reminder, this old patchset (that I replied to) enhanced git am -s\nwith an option to add different signatures depending on\nthe option passed to the -s flag.\nE.g. I have\n[am \"a\"]\n signoff = \"Acked-by: Michael S. Tsirkin \"\n\n[am \"r\"]\n signoff = \"Reviewed-by: Michael S. Tsirkin \"\n\n[am \"t\"]\n signoff = \"Tested-by: Michael S. Tsirkin \"\n\nand now:\n\tgit am -s art\nadds all 3 signatures when applying the patch.\n\n\nAny help will be appreciated.\n\n-- \nMST\n"},{"id":"249744","messageId":"xmqqbnq7leqe.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"20140922140144.GA9769@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-22T17:58:01Z","receivedAt":"2014-09-22T17:58:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n> Hi Junio, Christian,\n> it's been a while.\n> I see that the work on trailers is going on.\n> I tried going over the documentation but I could not figure\n> out how would one implement multiple signatures using the\n> trailers mechanism.\n\nGood. Christian has been rerolling the series numerous times but he\nhas been working without getting much input from people who would\nenvision using the mechanism themselves (and my comments on the\nseries do not count because I am not as one of them).\n\nPlease bombard us with questions and usability improvement\nsuggestions ;-)\n"},{"id":"249767","messageId":"CAP8UFD2W1r9859FgpBXqvdNLAfXoCwjpEFpTKXU6fGuC_8uvBg@mail.gmail.com","threadId":"36899","inReplyTo":"20140922140144.GA9769@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-09-23T07:45:50Z","receivedAt":"2014-09-23T07:45:50Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Michael,\n\nOn Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin wrote:\n>\n> Hi Junio, Christian,\n> it's been a while.\n> I see that the work on trailers is going on.\n> I tried going over the documentation but I could not figure\n> out how would one implement multiple signatures using the\n> trailers mechanism.\n>\n> As a reminder, this old patchset (that I replied to) enhanced git am -s\n> with an option to add different signatures depending on\n> the option passed to the -s flag.\n> E.g. I have\n> [am \"a\"]\n> signoff = \"Acked-by: Michael S. Tsirkin \"\n>\n> [am \"r\"]\n> signoff = \"Reviewed-by: Michael S. Tsirkin \"\n>\n> [am \"t\"]\n> signoff = \"Tested-by: Michael S. Tsirkin \"\n>\n> and now:\n> git am -s art\n> adds all 3 signatures when applying the patch.\n\nThis is probably not as simple as you would like but it works with\nsomething like:\n\n$ git interpret-trailers --trailer \"Acked-by: Michael S. Tsirkin\n\" --trailer \"Reviewed-by: Michael S. Tsirkin\n\" --trailer \"Tested-by: Michael S. Tsirkin\n\" 0001-foo.patch >to_apply/0001-foo.patch\n\nand then:\n\n$ git am to_apply/*.patch\n\nAlso by using something like:\n\n$ git config trailer.a.key Acked-by\n$ git config trailer.r.key Reviewed-by\n$ git config trailer.t.key Tested-by\n\nthe first command could be simplified to:\n\n$ git interpret-trailers --trailer \"a: Michael S. Tsirkin\n\" --trailer \"r: Michael S. Tsirkin \"\n--trailer \"t: Michael S. Tsirkin \" 0001-foo.patch\n>to_apply/0001-foo.patch\n\nAnd if you use an env variable:\n\n$ ME=\"Michael S. Tsirkin \"\n$ git interpret-trailers --trailer \"a: $ME\" --trailer \"r: $ME\"\n--trailer \"t: $ME\" 0001-foo.patch >to_apply/0001-foo.patch\n\nMaybe later we will integrate git interpret-trailers with git commit,\ngit am and other commands, so that you can do directly:\n\ngit am --trailer \"a: $ME\" --trailer \"r: $ME\" --trailer \"t: $ME\" 0001-foo.patch\n\nMaybe we wil also assign a one letter shortcut to --trailer, for\nexample \"z\", so that could be:\n\ngit am -z \"a: $ME\" -z \"r: $ME\" -z \"t: $ME\" 0001-foo.patch\n\nWe could also allow many separators in the same -z argument as long as\nthey are separated by say \"~\", so you could have:\n\ngit am -z \"a: $ME~r: $ME~t: $ME\" 0001-foo.patch\n\nAnd then we could also allow people to define default values for\ntrailers with something like:\n\n$ git config trailer.a.defaultvalue \"Michael S. Tsirkin \"\n$ git config trailer.r.defaultvalue \"Michael S. Tsirkin \"\n$ git config trailer.t.defaultvalue \"Michael S. Tsirkin \"\n\nSo that in the end you could have:\n\ngit am -z a~r~t 0001-foo.patch\n\nwhich is very close to \"git am -s art\".\n\nBest,\nChristian.\n"},{"id":"249772","messageId":"20140923080700.GA16527@redhat.com","threadId":"36899","inReplyTo":"CAP8UFD2W1r9859FgpBXqvdNLAfXoCwjpEFpTKXU6fGuC_8uvBg@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-09-23T08:07:00Z","receivedAt":"2014-09-23T08:07:00Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:\n> Hi Michael,\n> \n> On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin wrote:\n> >\n> > Hi Junio, Christian,\n> > it's been a while.\n> > I see that the work on trailers is going on.\n> > I tried going over the documentation but I could not figure\n> > out how would one implement multiple signatures using the\n> > trailers mechanism.\n> >\n> > As a reminder, this old patchset (that I replied to) enhanced git am -s\n> > with an option to add different signatures depending on\n> > the option passed to the -s flag.\n> > E.g. I have\n> > [am \"a\"]\n> > signoff = \"Acked-by: Michael S. Tsirkin \"\n> >\n> > [am \"r\"]\n> > signoff = \"Reviewed-by: Michael S. Tsirkin \"\n> >\n> > [am \"t\"]\n> > signoff = \"Tested-by: Michael S. Tsirkin \"\n> >\n> > and now:\n> > git am -s art\n> > adds all 3 signatures when applying the patch.\n> \n> This is probably not as simple as you would like but it works with\n> something like:\n> \n> $ git interpret-trailers --trailer \"Acked-by: Michael S. Tsirkin\n> \" --trailer \"Reviewed-by: Michael S. Tsirkin\n> \" --trailer \"Tested-by: Michael S. Tsirkin\n> \" 0001-foo.patch >to_apply/0001-foo.patch\n> \n> and then:\n> \n> $ git am to_apply/*.patch\n> \n> Also by using something like:\n> \n> $ git config trailer.a.key Acked-by\n> $ git config trailer.r.key Reviewed-by\n> $ git config trailer.t.key Tested-by\n\nI would like multiple keys to match a specific\nletter, e.g. as a maintainer I need\nboth reviewed by and signed off by when I\napply a patch, I like applying them with\na single \"-s m\".\n\n> the first command could be simplified to:\n> \n> $ git interpret-trailers --trailer \"a: Michael S. Tsirkin\n> \" --trailer \"r: Michael S. Tsirkin \"\n> --trailer \"t: Michael S. Tsirkin \" 0001-foo.patch\n> >to_apply/0001-foo.patch\n> \n> And if you use an env variable:\n> \n> $ ME=\"Michael S. Tsirkin \"\n> $ git interpret-trailers --trailer \"a: $ME\" --trailer \"r: $ME\"\n> --trailer \"t: $ME\" 0001-foo.patch >to_apply/0001-foo.patch\n> \n> Maybe later we will integrate git interpret-trailers with git commit,\n> git am and other commands, so that you can do directly:\n> \n> git am --trailer \"a: $ME\" --trailer \"r: $ME\" --trailer \"t: $ME\" 0001-foo.patch\n> \n> Maybe we wil also assign a one letter shortcut to --trailer, for\n> example \"z\", so that could be:\n> \n> git am -z \"a: $ME\" -z \"r: $ME\" -z \"t: $ME\" 0001-foo.patch\n\n-s could apply here, right?\nIt doesn't have a parameter at the moment.\n\n> We could also allow many separators in the same -z argument as long as\n> they are separated by say \"~\",\n\nI think -z a -z r -z t is enough.\n\n> so you could have:\n> \n> git am -z \"a: $ME~r: $ME~t: $ME\" 0001-foo.patch\n> \n> And then we could also allow people to define default values for\n> trailers with something like:\n> \n> $ git config trailer.a.defaultvalue \"Michael S. Tsirkin \"\n> $ git config trailer.r.defaultvalue \"Michael S. Tsirkin \"\n> $ git config trailer.t.defaultvalue \"Michael S. Tsirkin \"\n\nI'm kind of confused by the key/value concept.\nCan't I define the whole 'Acked-by: Michael S. Tsirkin '\nstring as the key?\n\n\n> So that in the end you could have:\n> \n> git am -z a~r~t 0001-foo.patch\n> \n> which is very close to \"git am -s art\".\n> \n> Best,\n> Christian.\n\nIf I figure out the defaultvalue thing, I might\nfind the time to work on git am integration.\n"},{"id":"249800","messageId":"xmqqbnq6jm0s.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"CAP8UFD2W1r9859FgpBXqvdNLAfXoCwjpEFpTKXU6fGuC_8uvBg@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-23T17:15:47Z","receivedAt":"2014-09-23T17:15:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin wrote:\n>> ...\n>> As a reminder, this old patchset (that I replied to) enhanced git am -s\n>> with an option to add different signatures depending on\n>> the option passed to the -s flag.\n>> E.g. I have\n>> [am \"a\"]\n>> signoff = \"Acked-by: Michael S. Tsirkin \"\n>>\n>> [am \"r\"]\n>> signoff = \"Reviewed-by: Michael S. Tsirkin \"\n>>\n>> [am \"t\"]\n>> signoff = \"Tested-by: Michael S. Tsirkin \"\n>>\n>> and now:\n>> git am -s art\n>> adds all 3 signatures when applying the patch.\n>\n> This is probably not as simple as you would like but it works with\n> something like:\n>\n> $ git interpret-trailers --trailer \"Acked-by: Michael S. Tsirkin\n> \" --trailer \"Reviewed-by: Michael S. Tsirkin\n> \" --trailer \"Tested-by: Michael S. Tsirkin\n> \" 0001-foo.patch >to_apply/0001-foo.patch\n>\n> and then:\n>\n> $ git am to_apply/*.patch\n\nIf I understand it correctly, Michael is envisioning to implement\nhis \"git am -s art\" (I would recommend against reusing -s for this,\nthough. \"git am --trailer art\" is fine) and doing so by using\ninterpret-trailers as an internal implementation detail, so I would\nsay the above is a perfectly fine way to do so. An equivalent of\nthat command line is synthesized and run internally in his version\nof \"git am\" when his \"git am\" sees \"--trailer art\" option using\nthose am.{\"a\",\"r\",\"t\"}.trailer configuration variables.\n\n> Also by using something like:\n>\n> $ git config trailer.a.key Acked-by\n> $ git config trailer.r.key Reviewed-by\n> $ git config trailer.t.key Tested-by\n>\n> the first command could be simplified to:\n\nSo I think this mechanism buys Michael's use case very little, if\nany. It might be useful in other contexts, though.\n\nWhat would be more interesting is if the primitives you have,\ne.g. \"replace\", \"append\", etc. are sufficient to express his use\ncase and similar ones. For example, when working on multiple\ntrailers (e.g. \"am --trailer art\" would muck with three kinds), how\nshould \"do this if exists at the end and do that otherwise\" work?\nTo an existing message ends with Michael's Signed-off-by:, if his\n\"git am --trailer arts\" is called to add these three and then a\nSigned-off-by: from him, should it add an extra S-o-b (because his\nexisting S-o-b will no longer be the last one after adding Acked and\nothers), or should it refrain from doing so? Can you express both\npreferences?\n\nAnother thing that got me wondered this morning while I was thinking\nabout this topic was if \"replace\" is flexible enough. We may want\nto have \"if an entry exists (not necessarily at the end), remove it\nand then append a new one with this value at the end\" to implement\n\"Last-tested-by: me@my.domain\", for example.\n"},{"id":"249826","messageId":"CAP8UFD2FV2pvR4+N0fDLtentA_oWwYGRZ6rPtshi=TOAvXaRLA@mail.gmail.com","threadId":"36899","inReplyTo":"20140923080700.GA16527@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-09-24T10:00:40Z","receivedAt":"2014-09-24T10:00:40Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Sep 23, 2014 at 10:07 AM, Michael S. Tsirkin wrote:\n> On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:\n>> This is probably not as simple as you would like but it works with\n>> something like:\n>>\n>> $ git interpret-trailers --trailer \"Acked-by: Michael S. Tsirkin\n>> \" --trailer \"Reviewed-by: Michael S. Tsirkin\n>> \" --trailer \"Tested-by: Michael S. Tsirkin\n>> \" 0001-foo.patch >to_apply/0001-foo.patch\n>>\n>> and then:\n>>\n>> $ git am to_apply/*.patch\n>>\n>> Also by using something like:\n>>\n>> $ git config trailer.a.key Acked-by\n>> $ git config trailer.r.key Reviewed-by\n>> $ git config trailer.t.key Tested-by\n>\n> I would like multiple keys to match a specific\n> letter, e.g. as a maintainer I need\n> both reviewed by and signed off by when I\n> apply a patch, I like applying them with\n> a single \"-s m\".\n\nThat's different from what you implemented in your patch.\nAnd franckly I think that for this kind of specific use cases, you\ncould create your own aliases, either Git aliases or just shell\naliases.\n\nFor example if we implement default values and make git am call git\ninterpret-trailers, a shell alias could simply be:\n\nalias gamsm='git am --trailer r --trailer s'\n\nI use \"git log --oneline --decorate --graph\" very often, so I made my\nown alias for it, and I suppose a lot of other people have done so.\n\nThe number of people who will use trailers will probably be much\nsmaller than the number of people using git log, so if we don't make\nshortcuts for \"git log --oneline --decorate --graph\", I see no ground\nto ask for a specific shortcut that adds both a reviewed by and a\nsigned off by.\n\n>> the first command could be simplified to:\n>>\n>> $ git interpret-trailers --trailer \"a: Michael S. Tsirkin\n>> \" --trailer \"r: Michael S. Tsirkin \"\n>> --trailer \"t: Michael S. Tsirkin \" 0001-foo.patch\n>> >to_apply/0001-foo.patch\n>>\n>> And if you use an env variable:\n>>\n>> $ ME=\"Michael S. Tsirkin \"\n>> $ git interpret-trailers --trailer \"a: $ME\" --trailer \"r: $ME\"\n>> --trailer \"t: $ME\" 0001-foo.patch >to_apply/0001-foo.patch\n>>\n>> Maybe later we will integrate git interpret-trailers with git commit,\n>> git am and other commands, so that you can do directly:\n>>\n>> git am --trailer \"a: $ME\" --trailer \"r: $ME\" --trailer \"t: $ME\" 0001-foo.patch\n>>\n>> Maybe we wil also assign a one letter shortcut to --trailer, for\n>> example \"z\", so that could be:\n>>\n>> git am -z \"a: $ME\" -z \"r: $ME\" -z \"t: $ME\" 0001-foo.patch\n>\n> -s could apply here, right?\n\nI don't know what we will do with -s. Maybe if we use -z, we don't need -s.\n\n> It doesn't have a parameter at the moment.\n\nWe will have to discuss that kind of thing when we make it possible\nfor git commit, git am and maybe other commands to accept trailers\narguments and pass them to git interpret-trailers.\n\nIn his email Junio seems to say that we don't need a shortcut like -z,\nwe could only have --trailer.\nAnd I think that it is indeed sound to at least wait a little before\nusing up one shortcut like -z in many commands.\n\n>> We could also allow many separators in the same -z argument as long as\n>> they are separated by say \"~\",\n>\n> I think -z a -z r -z t is enough.\n\nGreat! I think you will likely have at least \"--trailer a --trailer r\n--trailer t\", but I don't think it is too bad as you can use aliases\nto make it shorter to type.\n\n>> so you could have:\n>>\n>> git am -z \"a: $ME~r: $ME~t: $ME\" 0001-foo.patch\n>>\n>> And then we could also allow people to define default values for\n>> trailers with something like:\n>>\n>> $ git config trailer.a.defaultvalue \"Michael S. Tsirkin \"\n>> $ git config trailer.r.defaultvalue \"Michael S. Tsirkin \"\n>> $ git config trailer.t.defaultvalue \"Michael S. Tsirkin \"\n>\n> I'm kind of confused by the key/value concept.\n\nA \"defaultvalue\" would be the value used when no value is passed.\nThe \"key\" is just what we will use in the first part of the trailer\n(the part before the separator).\n\nFor example with the above \"defaultvalue\" and \"key\", \"--trailer a:\nJunio \" would add:\n\nAcked-by: Junio \n\nwhile \"--trailer a\" would add:\n\nAcked-by: Michael S. Tsirkin \n\n> Can't I define the whole 'Acked-by: Michael S. Tsirkin '\n> string as the key?\n\nThe whole 'Acked-by: Michael S. Tsirkin ' is a full\ntrailer, not a \"key\".\n\nAnd it is not possible right now to define a full trailer. Maybe we\ncould find a way to make it possible, but a default value and a way to\nhave a small nickname for the token (like \"a\" for \"Acked-by\") should\nget people quite far. And then for very specific use cases, it may be\nbetter to use aliases anyway.\n\n>> So that in the end you could have:\n>>\n>> git am -z a~r~t 0001-foo.patch\n>>\n>> which is very close to \"git am -s art\".\n>\n> If I figure out the defaultvalue thing, I might\n> find the time to work on git am integration.\n\nThat would be great!\n\nThanks,\nChristian.\n"},{"id":"249840","messageId":"xmqq1tr0cmuv.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"xmqqbnq6jm0s.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-25T05:04:08Z","receivedAt":"2014-09-25T05:04:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> What would be more interesting is if the primitives you have,\n> e.g. \"replace\", \"append\", etc. are sufficient to express his use\n> case and similar ones. For example, when working on multiple\n> trailers (e.g. \"am --trailer art\" would muck with three kinds), how\n> should \"do this if exists at the end and do that otherwise\" work?\n> To an existing message ends with Michael's Signed-off-by:, if his\n> \"git am --trailer arts\" is called to add these three and then a\n> Signed-off-by: from him, should it add an extra S-o-b (because his\n> existing S-o-b will no longer be the last one after adding Acked and\n> others), or should it refrain from doing so? Can you express both\n> preferences?\n\nBy the way, the answer to this can be \"no, but it does not matter.\",\nof course. If you can only express the latter (i.e. the addition of\nmultiple trailers is done as an atomic event, what was the last\nbefore addition of them will be treated during the whole time of\naddition of all of them), that may be perfectly fine because the\nformer (i.e. the addition is done one by one) can easily be emulated\nby calling the program multiple times, feeding the trailers one by\none.\n\n> Another thing that got me wondered this morning while I was thinking\n> about this topic was if \"replace\" is flexible enough. We may want\n> to have \"if an entry exists (not necessarily at the end), remove it\n> and then append a new one with this value at the end\" to implement\n> \"Last-tested-by: me@my.domain\", for example.\n"},{"id":"249844","messageId":"CAP8UFD0kfSBhSwu5Mb46XEHqYCE0SEsZd_3c0Sm4WzEc-NNc7w@mail.gmail.com","threadId":"36899","inReplyTo":"xmqqbnq6jm0s.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-09-25T10:04:48Z","receivedAt":"2014-09-25T10:04:48Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Sep 23, 2014 at 7:15 PM, Junio C Hamano wrote:\n> Christian Couder writes:\n>\n>>\n>> This is probably not as simple as you would like but it works with\n>> something like:\n>>\n>> $ git interpret-trailers --trailer \"Acked-by: Michael S. Tsirkin\n>> \" --trailer \"Reviewed-by: Michael S. Tsirkin\n>> \" --trailer \"Tested-by: Michael S. Tsirkin\n>> \" 0001-foo.patch >to_apply/0001-foo.patch\n>>\n>> and then:\n>>\n>> $ git am to_apply/*.patch\n>\n> If I understand it correctly, Michael is envisioning to implement\n> his \"git am -s art\" (I would recommend against reusing -s for this,\n> though. \"git am --trailer art\" is fine) and doing so by using\n> interpret-trailers as an internal implementation detail, so I would\n> say the above is a perfectly fine way to do so. An equivalent of\n> that command line is synthesized and run internally in his version\n> of \"git am\" when his \"git am\" sees \"--trailer art\" option using\n> those am.{\"a\",\"r\",\"t\"}.trailer configuration variables.\n\nYeah, that's the idea, except that I think \"--trailer art\" should mean\na trailer like:\n\nart: \n\n(if there is no trailer.art.key config variable defined).\n\nHaving am.{\"a\",\"r\",\"t\"}.trailer configuration variables to define full\ntrailers seems too specific and quite confusing regarding how git\ninterpret-trailers work without those variables.\n\n>> Also by using something like:\n>>\n>> $ git config trailer.a.key Acked-by\n>> $ git config trailer.r.key Reviewed-by\n>> $ git config trailer.t.key Tested-by\n>>\n>> the first command could be simplified to:\n>\n> So I think this mechanism buys Michael's use case very little, if\n> any. It might be useful in other contexts, though.\n>\n> What would be more interesting is if the primitives you have,\n> e.g. \"replace\", \"append\", etc. are sufficient to express his use\n> case and similar ones. For example, when working on multiple\n> trailers (e.g. \"am --trailer art\" would muck with three kinds), how\n> should \"do this if exists at the end and do that otherwise\" work?\n\nThe way the \"trailer..ifexists\" and \"trailer..where\" work is\nquite orthogonal to the way we decide what the content of the trailer\nis.\nIf we make \"--trailer art\" mean \"--trailer Acked-by: Michael --trailer\nReviewed-by: Michael --trailer Tested-by: Michael\", then it should\nwork as if we had passed the latter to the command line.\n\n> To an existing message ends with Michael's Signed-off-by:, if his\n> \"git am --trailer arts\" is called to add these three and then a\n> Signed-off-by: from him, should it add an extra S-o-b (because his\n> existing S-o-b will no longer be the last one after adding Acked and\n> others), or should it refrain from doing so? Can you express both\n> preferences?\n\nThe default for \"trailer.where\" is \"end\", and for \"trailer.ifexists\"\nit is \"addIfDifferentNeighbor\".\nThat means that by default it will add the four new trailers at the end.\n\nIf either \"trailer.ifexists\" or \"trailer.S-o-b.ifexists\" is set to\n\"addIfDifferent\", then only the first 3 new trailers will be added at\nthe end. So yes you can express both preferences.\n\n> Another thing that got me wondered this morning while I was thinking\n> about this topic was if \"replace\" is flexible enough. We may want\n> to have \"if an entry exists (not necessarily at the end), remove it\n> and then append a new one with this value at the end\" to implement\n> \"Last-tested-by: me@my.domain\", for example.\n\nThat's what \"replace\" does already. That's why I changed the previous\nname for this option from \"overwrite\" to \"replace\". You have an\n\"overwrite behavior\" with where = after and ifexist = replace, and you\nhave a \"remove old one and append new one behavior\" with where = end\nand ifexist = replace.\n\nThanks,\nChristian.\n"},{"id":"249849","messageId":"CAPc5daUTKU1JepLuyVC1Nk6LG4AZ2TA5SEYLsTSPbPKkauzNyQ@mail.gmail.com","threadId":"36899","inReplyTo":"CAP8UFD0kfSBhSwu5Mb46XEHqYCE0SEsZd_3c0Sm4WzEc-NNc7w@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-09-25T16:20:42Z","receivedAt":"2014-09-25T16:20:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Thu, Sep 25, 2014 at 3:04 AM, Christian Couder\n wrote:\n>> To an existing message ends with Michael's Signed-off-by:, if his\n>> \"git am --trailer arts\" is called to add these three and then a\n>> Signed-off-by: from him, should it add an extra S-o-b (because his\n>> existing S-o-b will no longer be the last one after adding Acked and\n>> others), or should it refrain from doing so? Can you express both\n>> preferences?\n>\n> The default for \"trailer.where\" is \"end\", and for \"trailer.ifexists\"\n> it is \"addIfDifferentNeighbor\".\n> That means that by default it will add the four new trailers at the end.\n>\n> If either \"trailer.ifexists\" or \"trailer.S-o-b.ifexists\" is set to\n> \"addIfDifferent\", then only the first 3 new trailers will be added at\n> the end. So yes you can express both preferences.\n\nSuppose that the original ends with Sob, and Michael's \"am\" invokes\ninterpret-trailers with Acked/Reviewed/Tested/Sob in this order. The first\nthree are set to addifDifferent and Sob is set to addIfDifferentNeighbor,\nwhich would be the traditional and sensible default.\n\nNow, how is addIfDifferentNeighbor interpreted? Adding the new Sob\nwith this single request to add these four is done on a message that\nhas the same Sob at the end (i.e. Neighbor). Does _you_ adding of\nAcked/Reviewed/Tested invalidate the Neighbor-ness and you add the\nSob anew?\n\nIf that is what happens, it is not a workable workaround to set Sob to\naddIfDifferent only for this invocation.\n\nAlternatively, if Neighbor-ness is evaluated first before you add A/R/T\nin response to this request, then you'd refrain from adding a duplicate\nSob. It wasn't quite clear from your description what your design was,\nand your explanation above is not still clear, at least to me.\n"},{"id":"249963","messageId":"20140928.133623.1635797151132857721.chriscool@tuxfamily.org","threadId":"36899","inReplyTo":"CAPc5daUTKU1JepLuyVC1Nk6LG4AZ2TA5SEYLsTSPbPKkauzNyQ@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2014-09-28T11:36:23Z","receivedAt":"2014-09-28T11:36:23Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"From: Junio C Hamano \n> On Thu, Sep 25, 2014 at 3:04 AM, Christian Couder\n> wrote:\n>>> To an existing message ends with Michael's Signed-off-by:, if his\n>>> \"git am --trailer arts\" is called to add these three and then a\n>>> Signed-off-by: from him, should it add an extra S-o-b (because his\n>>> existing S-o-b will no longer be the last one after adding Acked and\n>>> others), or should it refrain from doing so? Can you express both\n>>> preferences?\n>>\n>> The default for \"trailer.where\" is \"end\", and for \"trailer.ifexists\"\n>> it is \"addIfDifferentNeighbor\".\n>> That means that by default it will add the four new trailers at the end.\n>>\n>> If either \"trailer.ifexists\" or \"trailer.S-o-b.ifexists\" is set to\n>> \"addIfDifferent\", then only the first 3 new trailers will be added at\n>> the end. So yes you can express both preferences.\n> \n> Suppose that the original ends with Sob, and Michael's \"am\" invokes\n> interpret-trailers with Acked/Reviewed/Tested/Sob in this order. The first\n> three are set to addifDifferent and Sob is set to addIfDifferentNeighbor,\n> which would be the traditional and sensible default.\n> \n> Now, how is addIfDifferentNeighbor interpreted? Adding the new Sob\n> with this single request to add these four is done on a message that\n> has the same Sob at the end (i.e. Neighbor). Does _you_ adding of\n> Acked/Reviewed/Tested invalidate the Neighbor-ness and you add the\n> Sob anew?\n\nThe trailers are processed in the order they appear on the command\nline. And when a trailer is processed, the input message it \"sees\" is\nthe result from the processing of all the previous trailers on the\ncommand line. It is not any more the original input message.\n\nSo after Acked/Reviewed/Tested have been added, when the S-o-b at the\nend of the command line is processed, it \"sees\" an input message that\nhas the Tested trailer at the end. That's why with\naddIfDifferentNeighbor the S-o-b will still be added at the end.\n\n> If that is what happens, it is not a workable workaround to set Sob to\n> addIfDifferent only for this invocation.\n\nSetting S-o-b to addIfDifferent for this invocation would not add the\nS-o-b at the end, because another S-o-b still exists in the input\nmessage \"seen\" when the last S-o-b is processed.\n\n> Alternatively, if Neighbor-ness is evaluated first before you add A/R/T\n> in response to this request, then you'd refrain from adding a duplicate\n> Sob. It wasn't quite clear from your description what your design was,\n> and your explanation above is not still clear, at least to me.\n\nI hope it is clearer now. Maybe I should add something in the doc to\nbetter explain how it works.\n\nThanks,\nChristian.\n"},{"id":"250317","messageId":"20141007212937.GA14632@redhat.com","threadId":"36899","inReplyTo":"xmqqbnq6jm0s.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-10-07T21:29:37Z","receivedAt":"2014-10-07T21:29:37Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Tue, Sep 23, 2014 at 10:15:47AM -0700, Junio C Hamano wrote:\n> Christian Couder writes:\n> \n> > On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin wrote:\n> >> ...\n> >> As a reminder, this old patchset (that I replied to) enhanced git am -s\n> >> with an option to add different signatures depending on\n> >> the option passed to the -s flag.\n> >> E.g. I have\n> >> [am \"a\"]\n> >> signoff = \"Acked-by: Michael S. Tsirkin \"\n> >>\n> >> [am \"r\"]\n> >> signoff = \"Reviewed-by: Michael S. Tsirkin \"\n> >>\n> >> [am \"t\"]\n> >> signoff = \"Tested-by: Michael S. Tsirkin \"\n> >>\n> >> and now:\n> >> git am -s art\n> >> adds all 3 signatures when applying the patch.\n> >\n> > This is probably not as simple as you would like but it works with\n> > something like:\n> >\n> > $ git interpret-trailers --trailer \"Acked-by: Michael S. Tsirkin\n> > \" --trailer \"Reviewed-by: Michael S. Tsirkin\n> > \" --trailer \"Tested-by: Michael S. Tsirkin\n> > \" 0001-foo.patch >to_apply/0001-foo.patch\n> >\n> > and then:\n> >\n> > $ git am to_apply/*.patch\n> \n> If I understand it correctly, Michael is envisioning to implement\n> his \"git am -s art\" (I would recommend against reusing -s for this,\n> though. \"git am --trailer art\" is fine) and doing so by using\n> interpret-trailers as an internal implementation detail, so I would\n> say the above is a perfectly fine way to do so. An equivalent of\n> that command line is synthesized and run internally in his version\n> of \"git am\" when his \"git am\" sees \"--trailer art\" option using\n> those am.{\"a\",\"r\",\"t\"}.trailer configuration variables.\n\nHmm I wonder why do you dislike reusing -s with a parameter for this.\nTo me, this looks like a superset of the default -s functionality: -s\nadds the default signature, -s \"x\" adds signature \"x\" ... Users don't\nreally care that one is implemented as a trailer and another isn't. In\nfact, default -s can be implemented as a trailer too, right?\n\nCould you clarify please?\n\n-- \nMST\n"},{"id":"250319","messageId":"20141007213329.GB14632@redhat.com","threadId":"36899","inReplyTo":"CAP8UFD2FV2pvR4+N0fDLtentA_oWwYGRZ6rPtshi=TOAvXaRLA@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2014-10-07T21:33:29Z","receivedAt":"2014-10-07T21:33:29Z","isPatch":true,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Sep 24, 2014 at 12:00:40PM +0200, Christian Couder wrote:\n> On Tue, Sep 23, 2014 at 10:07 AM, Michael S. Tsirkin wrote:\n> > On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:\n> >> This is probably not as simple as you would like but it works with\n> >> something like:\n> >>\n> >> $ git interpret-trailers --trailer \"Acked-by: Michael S. Tsirkin\n> >> \" --trailer \"Reviewed-by: Michael S. Tsirkin\n> >> \" --trailer \"Tested-by: Michael S. Tsirkin\n> >> \" 0001-foo.patch >to_apply/0001-foo.patch\n> >>\n> >> and then:\n> >>\n> >> $ git am to_apply/*.patch\n> >>\n> >> Also by using something like:\n> >>\n> >> $ git config trailer.a.key Acked-by\n> >> $ git config trailer.r.key Reviewed-by\n> >> $ git config trailer.t.key Tested-by\n> >\n> > I would like multiple keys to match a specific\n> > letter, e.g. as a maintainer I need\n> > both reviewed by and signed off by when I\n> > apply a patch, I like applying them with\n> > a single \"-s m\".\n> \n> That's different from what you implemented in your patch.\n> And franckly I think that for this kind of specific use cases, you\n> could create your own aliases, either Git aliases or just shell\n> aliases.\n> \n> For example if we implement default values and make git am call git\n> interpret-trailers, a shell alias could simply be:\n> \n> alias gamsm='git am --trailer r --trailer s'\n> \n> I use \"git log --oneline --decorate --graph\" very often, so I made my\n> own alias for it, and I suppose a lot of other people have done so.\n> \n> The number of people who will use trailers will probably be much\n> smaller than the number of people using git log, so if we don't make\n> shortcuts for \"git log --oneline --decorate --graph\", I see no ground\n> to ask for a specific shortcut that adds both a reviewed by and a\n> signed off by.\n\nI've been thinking: how about a generic ability to add option shortcuts\nfor commands in .config?\nFor example:\n\n[am \"-z\"]\n\tcommand = \"--trailer foobar\"\n\nwould replace any -z in git am command line with --trailer foobar.\n\n\nDoes this sound useful?\n\n\n> >> the first command could be simplified to:\n> >>\n> >> $ git interpret-trailers --trailer \"a: Michael S. Tsirkin\n> >> \" --trailer \"r: Michael S. Tsirkin \"\n> >> --trailer \"t: Michael S. Tsirkin \" 0001-foo.patch\n> >> >to_apply/0001-foo.patch\n> >>\n> >> And if you use an env variable:\n> >>\n> >> $ ME=\"Michael S. Tsirkin \"\n> >> $ git interpret-trailers --trailer \"a: $ME\" --trailer \"r: $ME\"\n> >> --trailer \"t: $ME\" 0001-foo.patch >to_apply/0001-foo.patch\n> >>\n> >> Maybe later we will integrate git interpret-trailers with git commit,\n> >> git am and other commands, so that you can do directly:\n> >>\n> >> git am --trailer \"a: $ME\" --trailer \"r: $ME\" --trailer \"t: $ME\" 0001-foo.patch\n> >>\n> >> Maybe we wil also assign a one letter shortcut to --trailer, for\n> >> example \"z\", so that could be:\n> >>\n> >> git am -z \"a: $ME\" -z \"r: $ME\" -z \"t: $ME\" 0001-foo.patch\n> >\n> > -s could apply here, right?\n> \n> I don't know what we will do with -s. Maybe if we use -z, we don't need -s.\n> \n> > It doesn't have a parameter at the moment.\n> \n> We will have to discuss that kind of thing when we make it possible\n> for git commit, git am and maybe other commands to accept trailers\n> arguments and pass them to git interpret-trailers.\n> \n> In his email Junio seems to say that we don't need a shortcut like -z,\n> we could only have --trailer.\n> And I think that it is indeed sound to at least wait a little before\n> using up one shortcut like -z in many commands.\n> \n> >> We could also allow many separators in the same -z argument as long as\n> >> they are separated by say \"~\",\n> >\n> > I think -z a -z r -z t is enough.\n> \n> Great! I think you will likely have at least \"--trailer a --trailer r\n> --trailer t\", but I don't think it is too bad as you can use aliases\n> to make it shorter to type.\n> \n> >> so you could have:\n> >>\n> >> git am -z \"a: $ME~r: $ME~t: $ME\" 0001-foo.patch\n> >>\n> >> And then we could also allow people to define default values for\n> >> trailers with something like:\n> >>\n> >> $ git config trailer.a.defaultvalue \"Michael S. Tsirkin \"\n> >> $ git config trailer.r.defaultvalue \"Michael S. Tsirkin \"\n> >> $ git config trailer.t.defaultvalue \"Michael S. Tsirkin \"\n> >\n> > I'm kind of confused by the key/value concept.\n> \n> A \"defaultvalue\" would be the value used when no value is passed.\n> The \"key\" is just what we will use in the first part of the trailer\n> (the part before the separator).\n> \n> For example with the above \"defaultvalue\" and \"key\", \"--trailer a:\n> Junio \" would add:\n> \n> Acked-by: Junio \n> \n> while \"--trailer a\" would add:\n> \n> Acked-by: Michael S. Tsirkin \n> \n> > Can't I define the whole 'Acked-by: Michael S. Tsirkin '\n> > string as the key?\n> \n> The whole 'Acked-by: Michael S. Tsirkin ' is a full\n> trailer, not a \"key\".\n> \n> And it is not possible right now to define a full trailer. Maybe we\n> could find a way to make it possible, but a default value and a way to\n> have a small nickname for the token (like \"a\" for \"Acked-by\") should\n> get people quite far. And then for very specific use cases, it may be\n> better to use aliases anyway.\n> \n> >> So that in the end you could have:\n> >>\n> >> git am -z a~r~t 0001-foo.patch\n> >>\n> >> which is very close to \"git am -s art\".\n> >\n> > If I figure out the defaultvalue thing, I might\n> > find the time to work on git am integration.\n> \n> That would be great!\n> \n> Thanks,\n> Christian.\n"},{"id":"250322","messageId":"20141007213859.GB24508@peff.net","threadId":"36899","inReplyTo":"20141007212937.GA14632@redhat.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-10-07T21:39:00Z","receivedAt":"2014-10-07T21:39:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 08, 2014 at 12:29:37AM +0300, Michael S. Tsirkin wrote:\n\n> > If I understand it correctly, Michael is envisioning to implement\n> > his \"git am -s art\" (I would recommend against reusing -s for this,\n> > though. \"git am --trailer art\" is fine) and doing so by using\n> > interpret-trailers as an internal implementation detail, so I would\n> > say the above is a perfectly fine way to do so. An equivalent of\n> > that command line is synthesized and run internally in his version\n> > of \"git am\" when his \"git am\" sees \"--trailer art\" option using\n> > those am.{\"a\",\"r\",\"t\"}.trailer configuration variables.\n> \n> Hmm I wonder why do you dislike reusing -s with a parameter for this.\n> To me, this looks like a superset of the default -s functionality: -s\n> adds the default signature, -s \"x\" adds signature \"x\" ... Users don't\n> really care that one is implemented as a trailer and another isn't. In\n> fact, default -s can be implemented as a trailer too, right?\n> \n> Could you clarify please?\n\nOptional parameters for arguments make backwards-compatibility tricky.\nIn this case, the command:\n\n git am -s mbox1 mbox2\n\nmeans \"apply the patches from mbox1 and mbox2, and signoff the patches\".\nUnder your scheme, it now means \"apply from mbox2, and use the trailer\nmbox1\".\n\nI think it would make more sense for \"-s\" to use a trailer called\n\"signoff\" if it is configured (and if not, have a baked-in \"signoff\"\ntrailer config that behaves like \"-s\" does now). So \"-s\" (and\n\"--signoff\") become \"sign off in the way I usually do for my project\",\nnot just \"add a signed-off-by line\". If you want to something more\nfancy, you have to use \"--trailer=...\".\n\nJust my two cents, as one who has not been closely following this\ndiscussion. Apologies if this idea was already presented and shot down.\n:)\n\n-Peff\n"},{"id":"250323","messageId":"xmqqppe3d0ct.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"20141007213859.GB24508@peff.net","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-07T21:41:06Z","receivedAt":"2014-10-07T21:41:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Optional parameters for arguments make backwards-compatibility tricky.\n> In this case, the command:\n>\n> git am -s mbox1 mbox2\n>\n> means \"apply the patches from mbox1 and mbox2, and signoff the patches\".\n> Under your scheme, it now means \"apply from mbox2, and use the trailer\n> mbox1\".\n\nThanks for saving me from typing ;-)\n"},{"id":"250529","messageId":"CAP8UFD1ATE-CtqXJyd7qDw-34RJ3ZQibHo6BSi+42hkaPNzz5w@mail.gmail.com","threadId":"36899","inReplyTo":"7viok7k0c0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-10-12T09:36:52Z","receivedAt":"2014-10-12T09:36:52Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Sep 28, 2014 at 9:32 PM, Junio C Hamano wrote:\n> Christian Couder writes:\n>\n>> From: Junio C Hamano \n>>\n>>> If that is what happens, it is not a workable workaround to set Sob to\n>>> addIfDifferent only for this invocation.\n>>\n>> Setting S-o-b to addIfDifferent for this invocation would not add the\n>> S-o-b at the end, because another S-o-b still exists in the input\n>> message \"seen\" when the last S-o-b is processed.\n>\n> So there is no workaround whatsoever, which is worse X-<.\n\nI think there might be a misunderstanding.\n\nWith v16 you can easily choose if you want to have the S-o-b in the\noutput or not, when there is already one, see:\n\n$ cat test.txt\n\nSigned-off-by: \n\n$ cat test.txt | git interpret-trailers --trailer 'Acked-by:\n' --trailer 'Reviewed-by: ' --trailer 'Tested-by:\n' --trailer 'Signed-off-by: '\n\nSigned-off-by: \nAcked-by: \nReviewed-by: \nTested-by: \nSigned-off-by: \n\n$ cat test.txt | git -c 'trailer.ifexists=addIfDifferent'\ninterpret-trailers --trailer 'Acked-by: ' --trailer\n'Reviewed-by: ' --trailer 'Tested-by: ' --trailer\n'Signed-off-by: '\n\nSigned-off-by: \nAcked-by: \nReviewed-by: \nTested-by: \n\nOr:\n\n$ cat test.txt | git -c\n'trailer.Signed-off-by.ifexists=addIfDifferent' interpret-trailers\n--trailer 'Acked-by: ' --trailer 'Reviewed-by: '\n--trailer 'Tested-by: ' --trailer 'Signed-off-by: '\n\nSigned-off-by: \nAcked-by: \nReviewed-by: \nTested-by: \n\n(There was a small bug in v15 with the last command above.)\n\n>>> Alternatively, if Neighbor-ness is evaluated first before you add A/R/T\n>>> in response to this request, then you'd refrain from adding a duplicate\n>>> Sob. It wasn't quite clear from your description what your design was,\n>>> and your explanation above is not still clear, at least to me.\n>>\n>> I hope it is clearer now. Maybe I should add something in the doc to\n>> better explain how it works.\n>\n> I doubt that it would help the users materially to document that we\n> chose to implement a less useful way when there are multiple ways in\n> which a feature can work, though.\n>\n> Unless I am mis-reading you and you are actually saying that the\n> users can emulate the \"atomic\" variant without much hassle by doing\n> X and Y, that is. If so, it would help readers to document them.\n\nIf you would like me to document the 3 above commands in an example, I\nam ok to do that.\n\nThanks,\nChristian.\n"},{"id":"250535","messageId":"CAP8UFD0Fx455GiM8EphkG=-vswR-GOD169EOgf2gJsGzTHS=SA@mail.gmail.com","threadId":"36899","inReplyTo":"CAP8UFD1ATE-CtqXJyd7qDw-34RJ3ZQibHo6BSi+42hkaPNzz5w@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2014-10-13T05:09:53Z","receivedAt":"2014-10-13T05:09:53Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Oct 12, 2014 at 11:36 AM, Christian Couder\n wrote:\n>\n> With v16 you can easily choose if you want to have the S-o-b in the\n> output or not, when there is already one, ...\n\nBy the way, I sent v16 just before the above email, but the series\nstill hasn't hit the mailing list.\nDid some of you guys in cc receive something?\n"},{"id":"250585","messageId":"xmqqlhoj1v82.fsf@gitster.dls.corp.google.com","threadId":"36899","inReplyTo":"CAP8UFD0Fx455GiM8EphkG=-vswR-GOD169EOgf2gJsGzTHS=SA@mail.gmail.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-13T22:05:33Z","receivedAt":"2014-10-13T22:05:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> On Sun, Oct 12, 2014 at 11:36 AM, Christian Couder\n> wrote:\n>>\n>> With v16 you can easily choose if you want to have the S-o-b in the\n>> output or not, when there is already one, ...\n>\n> By the way, I sent v16 just before the above email, but the series\n> still hasn't hit the mailing list.\n> Did some of you guys in cc receive something?\n\nI see them and picked them up to replace.\n\nAre these now ready for 'next'?\n"},{"id":"250598","messageId":"20141014.072911.995931063273261216.chriscool@tuxfamily.org","threadId":"36899","inReplyTo":"xmqqlhoj1v82.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH RFC] git-am: support any number of signatures","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2014-10-14T05:29:11Z","receivedAt":"2014-10-14T05:29:11Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"From: Junio C Hamano \n>\n> Christian Couder writes:\n> \n>> On Sun, Oct 12, 2014 at 11:36 AM, Christian Couder\n>> wrote:\n>>>\n>>> With v16 you can easily choose if you want to have the S-o-b in the\n>>> output or not, when there is already one, ...\n>>\n>> By the way, I sent v16 just before the above email, but the series\n>> still hasn't hit the mailing list.\n>> Did some of you guys in cc receive something?\n> \n> I see them and picked them up to replace.\n\nThanks!\n \n> Are these now ready for 'next'?\n\nYeah, I think so.\n\nThanks,\nChristian.\n"}]}