{"thread":{"id":"41944","subject":"git interpret-trailers with multiple keys","startedAt":"2016-04-06T16:12:56Z","lastAt":"2016-04-11T07:24:41Z","messageCount":12,"participants":["Michael S. Tsirkin","Matthieu Moy","Junio C Hamano","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"282768","messageId":"20160406191054-mutt-send-email-mst@redhat.com","threadId":"41944","inReplyTo":null,"subject":"git interpret-trailers with multiple keys","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-06T16:12:56Z","receivedAt":"2016-04-06T16:12:56Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"I have this in .git/config\n\n[trailer \"r\"]\n        key = Reviewed-by\n        command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n[trailer \"s\"]\n        key = Signed-off-by\n        command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n\nwhenever I run git interpret-trailers -t r I see these lines added:\n\nReviewed-by: Michael S. Tsirkin <mst@redhat.com\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com\nReviewed-by: Michael S. Tsirkin <mst@redhat.com\n\nWhy is Reviewed-by repeated?  Bug or feature?\n\n-- \nMST\n"},{"id":"282776","messageId":"vpqlh4qbrnt.fsf@anie.imag.fr","threadId":"41944","inReplyTo":"20160406191054-mutt-send-email-mst@redhat.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-04-06T16:58:30Z","receivedAt":"2016-04-06T16:58:30Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Michael S. Tsirkin\" <mst@redhat.com> writes:\n\n> I have this in .git/config\n>\n> [trailer \"r\"]\n>         key = Reviewed-by\n>         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> [trailer \"s\"]\n>         key = Signed-off-by\n>         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n>\n> whenever I run git interpret-trailers -t r I see these lines added:\n>\n> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>\n> Why is Reviewed-by repeated?  Bug or feature?\n\nThe first two lines are added unconditionally:\n\n$ echo | git interpret-trailers \n\nReviewed-by: Michael S. Tsirkin <mst@redhat.com\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com\n\nThe last line is added because you've asked for it with --trailer r.\n\nI don't think it's currently possible to get the behavior you seem to\nexpect, ie. to define trailer tokens fully (key and value) in your\nconfig file but use them only on request.\n\n(BTW, I think you wanted a closing > at the end)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"282779","messageId":"20160406201509-mutt-send-email-mst@redhat.com","threadId":"41944","inReplyTo":"vpqlh4qbrnt.fsf@anie.imag.fr","subject":"Re: git interpret-trailers with multiple keys","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-06T17:16:20Z","receivedAt":"2016-04-06T17:16:20Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Apr 06, 2016 at 06:58:30PM +0200, Matthieu Moy wrote:\n> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> \n> > I have this in .git/config\n> >\n> > [trailer \"r\"]\n> >         key = Reviewed-by\n> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> > [trailer \"s\"]\n> >         key = Signed-off-by\n> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> >\n> > whenever I run git interpret-trailers -t r I see these lines added:\n> >\n> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >\n> > Why is Reviewed-by repeated?  Bug or feature?\n> \n> The first two lines are added unconditionally:\n> \n> $ echo | git interpret-trailers \n> \n> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> \n> The last line is added because you've asked for it with --trailer r.\n> \n> I don't think it's currently possible to get the behavior you seem to\n> expect, ie. to define trailer tokens fully (key and value) in your\n> config file but use them only on request.\n> \n> (BTW, I think you wanted a closing > at the end)\n\nIs this worth fixing? It doesn't look like a behaviour anyone\nwould want...\n\n> -- \n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n"},{"id":"282781","messageId":"xmqq1t6iy6p9.fsf@gitster.mtv.corp.google.com","threadId":"41944","inReplyTo":"20160406201509-mutt-send-email-mst@redhat.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-06T17:42:42Z","receivedAt":"2016-04-06T17:42:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" <mst@redhat.com> writes:\n\n> On Wed, Apr 06, 2016 at 06:58:30PM +0200, Matthieu Moy wrote:\n>> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n>> \n>> > I have this in .git/config\n>> >\n>> > [trailer \"r\"]\n>> >         key = Reviewed-by\n>> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n>> > [trailer \"s\"]\n>> >         key = Signed-off-by\n>> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n>> >\n>> > whenever I run git interpret-trailers -t r I see these lines added:\n>> >\n>> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n>> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> >\n>> > Why is Reviewed-by repeated?  Bug or feature?\n>> \n>> The first two lines are added unconditionally:\n>> \n>> $ echo | git interpret-trailers \n>> \n>> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n>> \n>> The last line is added because you've asked for it with --trailer r.\n>> \n>> I don't think it's currently possible to get the behavior you seem to\n>> expect, ie. to define trailer tokens fully (key and value) in your\n>> config file but use them only on request.\n>> \n>> (BTW, I think you wanted a closing > at the end)\n>\n> Is this worth fixing? It doesn't look like a behaviour anyone\n> would want...\n\nCC'ing Christian who's done the \"trailers\" thing.\n\nPersonally, I do not think adding any configured trailers without\nbeing asked is a sensible behaviour, but it is likely that people\nalready depend on it, as we seem to see \"How do I configure to\nalways add this and that trailer?\" from time to time.  I do not\nthink it is unreasonable to disable the \"automatically add\neverything that is configured\" when the command line arguments ask\nfor some specific trailer, but I haven't thought deeply about it.\n\nAn additional (uninformed) observation is that the 'echo' looks like\nan ugly workaround for the lack of \"always use this string as the\nvalue\" configuration.  Perhaps next to trailer.<token>.command, we\nwould need trailer.<token>.value?\n"},{"id":"282787","messageId":"20160406212940-mutt-send-email-mst@redhat.com","threadId":"41944","inReplyTo":"xmqq1t6iy6p9.fsf@gitster.mtv.corp.google.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-06T19:30:22Z","receivedAt":"2016-04-06T19:30:22Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Apr 06, 2016 at 10:42:42AM -0700, Junio C Hamano wrote:\n> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> \n> > On Wed, Apr 06, 2016 at 06:58:30PM +0200, Matthieu Moy wrote:\n> >> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> >> \n> >> > I have this in .git/config\n> >> >\n> >> > [trailer \"r\"]\n> >> >         key = Reviewed-by\n> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> >> > [trailer \"s\"]\n> >> >         key = Signed-off-by\n> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> >> >\n> >> > whenever I run git interpret-trailers -t r I see these lines added:\n> >> >\n> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> >\n> >> > Why is Reviewed-by repeated?  Bug or feature?\n> >> \n> >> The first two lines are added unconditionally:\n> >> \n> >> $ echo | git interpret-trailers \n> >> \n> >> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> >> \n> >> The last line is added because you've asked for it with --trailer r.\n> >> \n> >> I don't think it's currently possible to get the behavior you seem to\n> >> expect, ie. to define trailer tokens fully (key and value) in your\n> >> config file but use them only on request.\n> >> \n> >> (BTW, I think you wanted a closing > at the end)\n> >\n> > Is this worth fixing? It doesn't look like a behaviour anyone\n> > would want...\n> \n> CC'ing Christian who's done the \"trailers\" thing.\n> \n> Personally, I do not think adding any configured trailers without\n> being asked is a sensible behaviour, but it is likely that people\n> already depend on it, as we seem to see \"How do I configure to\n> always add this and that trailer?\" from time to time.  I do not\n> think it is unreasonable to disable the \"automatically add\n> everything that is configured\" when the command line arguments ask\n> for some specific trailer, but I haven't thought deeply about it.\n> \n> An additional (uninformed) observation is that the 'echo' looks like\n> an ugly workaround for the lack of \"always use this string as the\n> value\" configuration.\n\nOr at least a default.\n\n> Perhaps next to trailer.<token>.command, we\n> would need trailer.<token>.value?\n\n\n-- \nMST\n"},{"id":"282823","messageId":"CAP8UFD0Pw+yhO1jZTAbMkZ5d-usu3rx5N0Se=PNL=N7DD-BPcA@mail.gmail.com","threadId":"41944","inReplyTo":"20160406212940-mutt-send-email-mst@redhat.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-04-07T02:28:21Z","receivedAt":"2016-04-07T02:28:21Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Apr 6, 2016 at 3:30 PM, Michael S. Tsirkin <mst@redhat.com> wrote:\n> On Wed, Apr 06, 2016 at 10:42:42AM -0700, Junio C Hamano wrote:\n>> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n>>\n>> > On Wed, Apr 06, 2016 at 06:58:30PM +0200, Matthieu Moy wrote:\n>> >> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n>> >>\n>> >> > I have this in .git/config\n>> >> >\n>> >> > [trailer \"r\"]\n>> >> >         key = Reviewed-by\n>> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n>> >> > [trailer \"s\"]\n>> >> >         key = Signed-off-by\n>> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n>> >> >\n>> >> > whenever I run git interpret-trailers -t r I see these lines added:\n>> >> >\n>> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n>> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> >> >\n>> >> > Why is Reviewed-by repeated?  Bug or feature?\n>> >>\n>> >> The first two lines are added unconditionally:\n>> >>\n>> >> $ echo | git interpret-trailers\n>> >>\n>> >> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n>> >>\n>> >> The last line is added because you've asked for it with --trailer r.\n\nYes, and because the default is to add the trailer at the end.\n\n>> >> I don't think it's currently possible to get the behavior you seem to\n>> >> expect, ie. to define trailer tokens fully (key and value) in your\n>> >> config file but use them only on request.\n\nYes, because you could define for example a function like this:\n\nreviewed() {\n    git interpret-trailers --trailer 'Reviewed-by: Michael S. Tsirkin\n<mst@redhat.com>' --in-place \"$@\"\n}\n\nSo it is kind of easy already to make things requestable.\n\nIf people really want some configured trailers to be used only on\nrequest, it is possible to add a config option for that.\n\n>> >> (BTW, I think you wanted a closing > at the end)\n>> >\n>> > Is this worth fixing? It doesn't look like a behaviour anyone\n>> > would want...\n>>\n>> CC'ing Christian who's done the \"trailers\" thing.\n>>\n>> Personally, I do not think adding any configured trailers without\n>> being asked is a sensible behaviour, but it is likely that people\n>> already depend on it, as we seem to see \"How do I configure to\n>> always add this and that trailer?\" from time to time.  I do not\n>> think it is unreasonable to disable the \"automatically add\n>> everything that is configured\" when the command line arguments ask\n>> for some specific trailer, but I haven't thought deeply about it.\n>>\n>> An additional (uninformed) observation is that the 'echo' looks like\n>> an ugly workaround for the lack of \"always use this string as the\n>> value\" configuration.\n>\n> Or at least a default.\n>\n>> Perhaps next to trailer.<token>.command, we\n>> would need trailer.<token>.value?\n\nYeah, that is possible too.\nIt could be bit redundant if we already have a config option to say if\nthe trailer has to be requested.\n"},{"id":"283100","messageId":"20160410182750-mutt-send-email-mst@redhat.com","threadId":"41944","inReplyTo":"CAP8UFD0Pw+yhO1jZTAbMkZ5d-usu3rx5N0Se=PNL=N7DD-BPcA@mail.gmail.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-10T15:32:49Z","receivedAt":"2016-04-10T15:32:49Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Wed, Apr 06, 2016 at 10:28:21PM -0400, Christian Couder wrote:\n> On Wed, Apr 6, 2016 at 3:30 PM, Michael S. Tsirkin <mst@redhat.com> wrote:\n> > On Wed, Apr 06, 2016 at 10:42:42AM -0700, Junio C Hamano wrote:\n> >> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> >>\n> >> > On Wed, Apr 06, 2016 at 06:58:30PM +0200, Matthieu Moy wrote:\n> >> >> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> >> >>\n> >> >> > I have this in .git/config\n> >> >> >\n> >> >> > [trailer \"r\"]\n> >> >> >         key = Reviewed-by\n> >> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> >> >> > [trailer \"s\"]\n> >> >> >         key = Signed-off-by\n> >> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> >> >> >\n> >> >> > whenever I run git interpret-trailers -t r I see these lines added:\n> >> >> >\n> >> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> >\n> >> >> > Why is Reviewed-by repeated?  Bug or feature?\n> >> >>\n> >> >> The first two lines are added unconditionally:\n> >> >>\n> >> >> $ echo | git interpret-trailers\n> >> >>\n> >> >> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> >> >>\n> >> >> The last line is added because you've asked for it with --trailer r.\n> \n> Yes, and because the default is to add the trailer at the end.\n> \n> >> >> I don't think it's currently possible to get the behavior you seem to\n> >> >> expect, ie. to define trailer tokens fully (key and value) in your\n> >> >> config file but use them only on request.\n> \n> Yes, because you could define for example a function like this:\n> \n> reviewed() {\n>     git interpret-trailers --trailer 'Reviewed-by: Michael S. Tsirkin\n> <mst@redhat.com>' --in-place \"$@\"\n> }\n> \n> So it is kind of easy already to make things requestable.\n\nNot if any commands are configured. interpret-trailers will\ninsist on running them in any case.\n\n> If people really want some configured trailers to be used only on\n> request, it is possible to add a config option for that.\n\nthis is not what the documentation says though:\n\n           If some <token>=<value> arguments are also passed on the\n\t\tcommand line, when a trailer.<token>.command is configured, the\n           command will also be executed for each of these arguments.\n\t\tAnd the <value> part of these arguments, if any, will be used to\n           replace the $ARG string in the command.\n\nso it says command *for a given token* is run.\n\nI would say that if people really want to run all trailers while also\npassing some on command line, *that* should be a config option.\nCurrent default violates the principle of least surprise.\n\n\n> >> >> (BTW, I think you wanted a closing > at the end)\n> >> >\n> >> > Is this worth fixing? It doesn't look like a behaviour anyone\n> >> > would want...\n> >>\n> >> CC'ing Christian who's done the \"trailers\" thing.\n> >>\n> >> Personally, I do not think adding any configured trailers without\n> >> being asked is a sensible behaviour, but it is likely that people\n> >> already depend on it, as we seem to see \"How do I configure to\n> >> always add this and that trailer?\" from time to time.  I do not\n> >> think it is unreasonable to disable the \"automatically add\n> >> everything that is configured\" when the command line arguments ask\n> >> for some specific trailer, but I haven't thought deeply about it.\n> >>\n> >> An additional (uninformed) observation is that the 'echo' looks like\n> >> an ugly workaround for the lack of \"always use this string as the\n> >> value\" configuration.\n> >\n> > Or at least a default.\n> >\n> >> Perhaps next to trailer.<token>.command, we\n> >> would need trailer.<token>.value?\n> \n> Yeah, that is possible too.\n> It could be bit redundant if we already have a config option to say if\n> the trailer has to be requested.\n\nSeems unrelated - if one just wants a string, using echo as\na command is inefficient and inconvenient.\n\n-- \nMST\n"},{"id":"283102","messageId":"CAP8UFD1hSg9RXLavzQgff-QioVU28_ZYhrfAvrhzNe8zXwwv5w@mail.gmail.com","threadId":"41944","inReplyTo":"20160410182750-mutt-send-email-mst@redhat.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-04-10T16:57:53Z","receivedAt":"2016-04-10T16:57:53Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Apr 10, 2016 at 11:32 AM, Michael S. Tsirkin <mst@redhat.com> wrote:\n> On Wed, Apr 06, 2016 at 10:28:21PM -0400, Christian Couder wrote:\n>> On Wed, Apr 6, 2016 at 3:30 PM, Michael S. Tsirkin <mst@redhat.com> wrote:\n>> > On Wed, Apr 06, 2016 at 10:42:42AM -0700, Junio C Hamano wrote:\n>> >> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n>> >>\n>> >> > On Wed, Apr 06, 2016 at 06:58:30PM +0200, Matthieu Moy wrote:\n>> >> >> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n>> >> >>\n>> >> >> > I have this in .git/config\n>> >> >> >\n>> >> >> > [trailer \"r\"]\n>> >> >> >         key = Reviewed-by\n>> >> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n>> >> >> > [trailer \"s\"]\n>> >> >> >         key = Signed-off-by\n>> >> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n>> >> >> >\n>> >> >> > whenever I run git interpret-trailers -t r I see these lines added:\n>> >> >> >\n>> >> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n>> >> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> >> >> >\n>> >> >> > Why is Reviewed-by repeated?  Bug or feature?\n>> >> >>\n>> >> >> The first two lines are added unconditionally:\n>> >> >>\n>> >> >> $ echo | git interpret-trailers\n>> >> >>\n>> >> >> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n>> >> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n>> >> >>\n>> >> >> The last line is added because you've asked for it with --trailer r.\n>>\n>> Yes, and because the default is to add the trailer at the end.\n>>\n>> >> >> I don't think it's currently possible to get the behavior you seem to\n>> >> >> expect, ie. to define trailer tokens fully (key and value) in your\n>> >> >> config file but use them only on request.\n>>\n>> Yes, because you could define for example a function like this:\n>>\n>> reviewed() {\n>>     git interpret-trailers --trailer 'Reviewed-by: Michael S. Tsirkin\n>> <mst@redhat.com>' --in-place \"$@\"\n>> }\n>>\n>> So it is kind of easy already to make things requestable.\n>\n> Not if any commands are configured. interpret-trailers will\n> insist on running them in any case.\n\nIf one want something requestable instead of automatic, one should\ndefinitely not configure any command.\n\n>> If people really want some configured trailers to be used only on\n>> request, it is possible to add a config option for that.\n>\n> this is not what the documentation says though:\n\nWhat I meant is that we could create new options called maybe\ntrailer.autocommands and trailer.<token>.autocommands that default to\n'true' and if 'false' the command would not be run automatically and\nthe corresponding trailer would not be added.\n\n> I would say that if people really want to run all trailers while also\n> passing some on command line, *that* should be a config option.\n> Current default violates the principle of least surprise.\n\nCurrent default is documented and is the most powerful default.\nYes, it might be surprising though.\n\n>> >> >> (BTW, I think you wanted a closing > at the end)\n>> >> >\n>> >> > Is this worth fixing? It doesn't look like a behaviour anyone\n>> >> > would want...\n>> >>\n>> >> CC'ing Christian who's done the \"trailers\" thing.\n>> >>\n>> >> Personally, I do not think adding any configured trailers without\n>> >> being asked is a sensible behaviour, but it is likely that people\n>> >> already depend on it, as we seem to see \"How do I configure to\n>> >> always add this and that trailer?\" from time to time.  I do not\n>> >> think it is unreasonable to disable the \"automatically add\n>> >> everything that is configured\" when the command line arguments ask\n>> >> for some specific trailer, but I haven't thought deeply about it.\n>> >>\n>> >> An additional (uninformed) observation is that the 'echo' looks like\n>> >> an ugly workaround for the lack of \"always use this string as the\n>> >> value\" configuration.\n>> >\n>> > Or at least a default.\n>> >\n>> >> Perhaps next to trailer.<token>.command, we\n>> >> would need trailer.<token>.value?\n>>\n>> Yeah, that is possible too.\n>> It could be bit redundant if we already have a config option to say if\n>> the trailer has to be requested.\n>\n> Seems unrelated - if one just wants a string, using echo as\n> a command is inefficient and inconvenient.\n\nEfficiency is not very high in the list for this kind of things. Also\nwhen these features were developed, many people wanted different\npowerful things and many people said they could help develop them\nthough very few did help. So if you think trailer.<token>.value is\nreally needed you are welcome to develop it.\n\nThanks,\nChristian.\n"},{"id":"283103","messageId":"20160410195958-mutt-send-email-mst@redhat.com","threadId":"41944","inReplyTo":"CAP8UFD1hSg9RXLavzQgff-QioVU28_ZYhrfAvrhzNe8zXwwv5w@mail.gmail.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-10T17:06:59Z","receivedAt":"2016-04-10T17:06:59Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Sun, Apr 10, 2016 at 06:57:53PM +0200, Christian Couder wrote:\n> On Sun, Apr 10, 2016 at 11:32 AM, Michael S. Tsirkin <mst@redhat.com> wrote:\n> > On Wed, Apr 06, 2016 at 10:28:21PM -0400, Christian Couder wrote:\n> >> On Wed, Apr 6, 2016 at 3:30 PM, Michael S. Tsirkin <mst@redhat.com> wrote:\n> >> > On Wed, Apr 06, 2016 at 10:42:42AM -0700, Junio C Hamano wrote:\n> >> >> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> >> >>\n> >> >> > On Wed, Apr 06, 2016 at 06:58:30PM +0200, Matthieu Moy wrote:\n> >> >> >> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> >> >> >>\n> >> >> >> > I have this in .git/config\n> >> >> >> >\n> >> >> >> > [trailer \"r\"]\n> >> >> >> >         key = Reviewed-by\n> >> >> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> >> >> >> > [trailer \"s\"]\n> >> >> >> >         key = Signed-off-by\n> >> >> >> >         command = \"echo \\\"Michael S. Tsirkin <mst@redhat.com\\\"\"\n> >> >> >> >\n> >> >> >> > whenever I run git interpret-trailers -t r I see these lines added:\n> >> >> >> >\n> >> >> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> >> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> >> >\n> >> >> >> > Why is Reviewed-by repeated?  Bug or feature?\n> >> >> >>\n> >> >> >> The first two lines are added unconditionally:\n> >> >> >>\n> >> >> >> $ echo | git interpret-trailers\n> >> >> >>\n> >> >> >> Reviewed-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com\n> >> >> >>\n> >> >> >> The last line is added because you've asked for it with --trailer r.\n> >>\n> >> Yes, and because the default is to add the trailer at the end.\n> >>\n> >> >> >> I don't think it's currently possible to get the behavior you seem to\n> >> >> >> expect, ie. to define trailer tokens fully (key and value) in your\n> >> >> >> config file but use them only on request.\n> >>\n> >> Yes, because you could define for example a function like this:\n> >>\n> >> reviewed() {\n> >>     git interpret-trailers --trailer 'Reviewed-by: Michael S. Tsirkin\n> >> <mst@redhat.com>' --in-place \"$@\"\n> >> }\n> >>\n> >> So it is kind of easy already to make things requestable.\n> >\n> > Not if any commands are configured. interpret-trailers will\n> > insist on running them in any case.\n> \n> If one want something requestable instead of automatic, one should\n> definitely not configure any command.\n\nThen one can't set any values, only keys.\n\n> >> If people really want some configured trailers to be used only on\n> >> request, it is possible to add a config option for that.\n> >\n> > this is not what the documentation says though:\n> \n> What I meant is that we could create new options called maybe\n> trailer.autocommands and trailer.<token>.autocommands that default to\n> 'true' and if 'false' the command would not be run automatically and\n> the corresponding trailer would not be added.\n> \n> > I would say that if people really want to run all trailers while also\n> > passing some on command line, *that* should be a config option.\n> > Current default violates the principle of least surprise.\n> \n> Current default is documented and is the most powerful default.\n\nI'm not sure what makes you say that. What makes it the most powerful?\n\n> Yes, it might be surprising though.\n> >> >> >> (BTW, I think you wanted a closing > at the end)\n> >> >> >\n> >> >> > Is this worth fixing? It doesn't look like a behaviour anyone\n> >> >> > would want...\n> >> >>\n> >> >> CC'ing Christian who's done the \"trailers\" thing.\n> >> >>\n> >> >> Personally, I do not think adding any configured trailers without\n> >> >> being asked is a sensible behaviour, but it is likely that people\n> >> >> already depend on it, as we seem to see \"How do I configure to\n> >> >> always add this and that trailer?\" from time to time.  I do not\n> >> >> think it is unreasonable to disable the \"automatically add\n> >> >> everything that is configured\" when the command line arguments ask\n> >> >> for some specific trailer, but I haven't thought deeply about it.\n> >> >>\n> >> >> An additional (uninformed) observation is that the 'echo' looks like\n> >> >> an ugly workaround for the lack of \"always use this string as the\n> >> >> value\" configuration.\n> >> >\n> >> > Or at least a default.\n> >> >\n> >> >> Perhaps next to trailer.<token>.command, we\n> >> >> would need trailer.<token>.value?\n> >>\n> >> Yeah, that is possible too.\n> >> It could be bit redundant if we already have a config option to say if\n> >> the trailer has to be requested.\n> >\n> > Seems unrelated - if one just wants a string, using echo as\n> > a command is inefficient and inconvenient.\n> \n> Efficiency is not very high in the list for this kind of things. Also\n> when these features were developed, many people wanted different\n> powerful things and many people said they could help develop them\n> though very few did help. So if you think trailer.<token>.value is\n> really needed you are welcome to develop it.\n> \n> Thanks,\n> Christian.\n"},{"id":"283105","messageId":"20160410203556-mutt-send-email-mst@redhat.com","threadId":"41944","inReplyTo":"CAP8UFD1hSg9RXLavzQgff-QioVU28_ZYhrfAvrhzNe8zXwwv5w@mail.gmail.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-10T17:43:01Z","receivedAt":"2016-04-10T17:43:01Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Sun, Apr 10, 2016 at 06:57:53PM +0200, Christian Couder wrote:\n> What I meant is that we could create new options called maybe\n> trailer.autocommands and trailer.<token>.autocommands that default to\n> 'true' and if 'false' the command would not be run automatically and\n> the corresponding trailer would not be added.\n\nI don't think it has to do with commands.\nFor example, if we add \"value\" it should behave the same.\n\nSo I think a better name is \"ifnotlisted\", with values \"add\"\nand \"donothing\".\n\nThoughts?\n\n-- \nMST\n"},{"id":"283128","messageId":"vpqegac7hab.fsf@anie.imag.fr","threadId":"41944","inReplyTo":"20160410203556-mutt-send-email-mst@redhat.com","subject":"Re: git interpret-trailers with multiple keys","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-04-11T07:09:48Z","receivedAt":"2016-04-11T07:09:48Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Michael S. Tsirkin\" <mst@redhat.com> writes:\n\n> On Sun, Apr 10, 2016 at 06:57:53PM +0200, Christian Couder wrote:\n>> What I meant is that we could create new options called maybe\n>> trailer.autocommands and trailer.<token>.autocommands that default to\n>> 'true' and if 'false' the command would not be run automatically and\n>> the corresponding trailer would not be added.\n>\n> I don't think it has to do with commands.\n> For example, if we add \"value\" it should behave the same.\n>\n> So I think a better name is \"ifnotlisted\", with values \"add\"\n> and \"donothing\".\n\nHaving a negation in the variable name feels wrong. When the token is\nlisted on the command-line and ifnotlisted=donothing, I have to apply a\ndouble-negation to guess what would happen (=> \"if listed then do\nsomething\").\n\nI agree that having such variable would be a good thing. It would solve\nyour issue (i.e. \"How to I configure a token for quick use from the\ncommand-line without applying it unconditionally\"), and allow full\nbackward compatibility.\n\nI'd call the option \"apply\" or perhaps \"run\", with values 1/true/always\n= default = current behavior, or \"auto\" = \"apply when asked from the\ncommand-line\". I'm wondering whether other values could make sense (not\nto implement it right now, but to keep the design open to further\nextensions): perhaps apply=ifauthor could mean \"apply this trailer to\npatches I'm the author of\" for example.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"283129","messageId":"20160411102346-mutt-send-email-mst@redhat.com","threadId":"41944","inReplyTo":"vpqegac7hab.fsf@anie.imag.fr","subject":"Re: git interpret-trailers with multiple keys","fromName":"Michael S. Tsirkin","fromEmail":"mst@redhat.com","sentAt":"2016-04-11T07:24:41Z","receivedAt":"2016-04-11T07:24:41Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"On Mon, Apr 11, 2016 at 09:09:48AM +0200, Matthieu Moy wrote:\n> \"Michael S. Tsirkin\" <mst@redhat.com> writes:\n> \n> > On Sun, Apr 10, 2016 at 06:57:53PM +0200, Christian Couder wrote:\n> >> What I meant is that we could create new options called maybe\n> >> trailer.autocommands and trailer.<token>.autocommands that default to\n> >> 'true' and if 'false' the command would not be run automatically and\n> >> the corresponding trailer would not be added.\n> >\n> > I don't think it has to do with commands.\n> > For example, if we add \"value\" it should behave the same.\n> >\n> > So I think a better name is \"ifnotlisted\", with values \"add\"\n> > and \"donothing\".\n> \n> Having a negation in the variable name feels wrong. When the token is\n> listed on the command-line and ifnotlisted=donothing, I have to apply a\n> double-negation to guess what would happen (=> \"if listed then do\n> something\").\n\nIsn't this similar to ifmissing?\n\n> I agree that having such variable would be a good thing. It would solve\n> your issue (i.e. \"How to I configure a token for quick use from the\n> command-line without applying it unconditionally\"), and allow full\n> backward compatibility.\n> \n> I'd call the option \"apply\" or perhaps \"run\", with values 1/true/always\n> = default = current behavior, or \"auto\" = \"apply when asked from the\n> command-line\". I'm wondering whether other values could make sense (not\n> to implement it right now, but to keep the design open to further\n> extensions): perhaps apply=ifauthor could mean \"apply this trailer to\n> patches I'm the author of\" for example.\n> \n> -- \n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n"}]}