From: Christian Couder <firstname.lastname@example.org> To: Jeremy Morton <email@example.com> Cc: Junio C Hamano <firstname.lastname@example.org>, Christian Couder <email@example.com>, git <firstname.lastname@example.org>, Johan Herland <email@example.com> Subject: Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers' Date: Tue, 29 Apr 2014 13:47:51 +0200 Message-ID: <CAP8UFD2oXpW9QEkSh+vpNGRAxRFp0zJF39ZZ8sUZLTcKB9mHWQ@mail.gmail.com> (raw) In-Reply-To: <535F8785.firstname.lastname@example.org> On Tue, Apr 29, 2014 at 1:05 PM, Jeremy Morton <email@example.com> wrote: > On 28/04/2014 17:37, Junio C Hamano wrote: >> >> Christian Couder<firstname.lastname@example.org> writes: >> >>> From: Junio C Hamano<email@example.com> >>>> >>>> >>>> Christian Couder<firstname.lastname@example.org> writes: >>>> ... >>> >>> >>>>> + trailer. After some alphanumeric characters, it can contain >>>>> + some non alphanumeric characters like ':', '=' or '#' that will >>>>> + be used instead of ':' to separate the token from the value in >>>>> + the trailer, though the default ':' is more standard. >>>> >>>> >>>> I assume that this is for things like >>>> >>>> bug #538 >>>> >>>> and the configuration would say something like: >>>> >>>> [trailer "bug"] >>>> key = "bug #" >>>> >>>> For completeness (of this example), the bog-standard s-o-b would >>>> look like >>>> >>>> Signed-off-by: Christian Couder<email@example.com> >>>> >>>> and the configuration for it that spell the redundant "key" would >>>> be: >>>> >>>> [trailer "Signed-off-by"] >>>> key = "Signed-off-by: " >>> >>> >>> Yeah, but you can use the following instead: >>> >>> [trailer "s-o-b"] >>> key = "Signed-off-by: " > > > One thing I'm not quite understanding is where the "Christian > Couder<firstname.lastname@example.org>" bit comes from. So you've defined the > trailer token and key, but interpret-trailers then needs to get the value it > will give for the key from somewhere. Does it have to just be hardcoded in? > We probably want some way to get various variables like current branch name, > current git version, etc. So in the case of always adding a trailer for the > branch that the commit was checked in to at the time (Developed-on, > Made-on-branch, Author-branch, etc. [I think my favourite is > Made-on-branch]), you'd want something like: > > [trailer "m-o-b"] > key = "Made-on-branch: " > value = "$currentBranch" > > ... resulting in the trailer (for example): > Made-on-branch: pacman-minigame In the documentation patch, there is: trailer.<token>.command:: This option can be used to specify a shell command that will be used to automatically add or modify a trailer with the specified 'token'. When this option is specified, it is like if a special 'token=value' argument is added at the end of the command line, where 'value' will be given by the standard output of the specified command. If the command contains the `$ARG` string, this string will be replaced with the 'value' part of an existing trailer with the same token, if any, before the command is launched. That's why Something like the following should work if "git commit" automitically runs "git interpret-trailers": [trailer "m-o-b"] key = "Made-on-branch: " command = "git name-rev --name-only HEAD" > Also, if there were no current branch name because you're committing in a > detached head state, it would be nice if you could have some logic to > determine that, and instead write the trailer as: > Made-on-branch: (detached HEAD: AB12CD34) You may need to write a small script for that. Then you just need the "trailer.m-o-b.command" config value to point to your script. > ... or whatever. And also how about some logic to be able to say that if > you're committing to the "master" branch, the trailer doesn't get inserted > at all? You can script that too. Best, Christian.
next prev parent reply index Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-04-06 17:01 [PATCH v10 00/12] Add interpret-trailers builtin Christian Couder 2014-04-06 17:01 ` [PATCH v10 01/12] trailer: add data structures and basic functions Christian Couder 2014-04-06 17:01 ` [PATCH v10 02/12] trailer: process trailers from stdin and arguments Christian Couder 2014-04-06 17:01 ` [PATCH v10 03/12] trailer: read and process config information Christian Couder 2014-04-06 17:01 ` [PATCH v10 04/12] trailer: process command line trailer arguments Christian Couder 2014-04-06 17:01 ` [PATCH v10 05/12] trailer: parse trailers from stdin Christian Couder 2014-04-06 17:01 ` [PATCH v10 06/12] trailer: put all the processing together and print Christian Couder 2014-04-06 17:01 ` [PATCH v10 07/12] trailer: add interpret-trailers command Christian Couder 2014-04-06 17:01 ` [PATCH v10 08/12] trailer: add tests for "git interpret-trailers" Christian Couder 2014-04-06 17:02 ` [PATCH v10 09/12] trailer: execute command from 'trailer.<name>.command' Christian Couder 2014-04-06 17:02 ` [PATCH v10 10/12] trailer: add tests for commands in config file Christian Couder 2014-04-06 17:02 ` [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers' Christian Couder 2014-04-08 7:30 ` Michael Haggerty 2014-04-08 11:35 ` Christian Couder 2014-04-08 15:25 ` Michael Haggerty 2014-04-25 21:07 ` Christian Couder 2014-04-28 10:16 ` Michael Haggerty 2014-05-25 8:37 ` Christian Couder 2014-05-27 8:21 ` Michael Haggerty 2014-05-27 9:17 ` Johan Herland 2014-05-27 19:18 ` Junio C Hamano 2014-04-08 16:52 ` Junio C Hamano 2014-04-08 21:26 ` Junio C Hamano 2014-04-25 19:56 ` Christian Couder 2014-04-28 16:37 ` Junio C Hamano 2014-04-29 11:05 ` Jeremy Morton 2014-04-29 11:47 ` Christian Couder [this message] 2014-04-29 13:25 ` Jeremy Morton 2014-05-01 18:54 ` Christian Couder 2014-04-29 13:25 ` Jeremy Morton 2014-04-06 17:02 ` [PATCH v10 12/12] trailer: add blank line before the trailers if needed Christian Couder 2014-04-07 21:38 ` Junio C Hamano 2014-04-08 12:48 ` Christian Couder
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAP8UFD2oXpW9QEkSh+vpNGRAxRFp0zJF39ZZ8sUZLTcKB9mHWQ@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Mailing List Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/git/0 git/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 git git/ https://lore.kernel.org/git \ email@example.com public-inbox-index git Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git