From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Git List" <git@vger.kernel.org>,
"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH 3/3] doc: give examples for send-email cc-cmd operation
Date: Mon, 20 Jul 2015 22:35:01 +0100 [thread overview]
Message-ID: <996C8C8A69844E44890D09811C57DAC8@PhilipOakley> (raw)
In-Reply-To: xmqqoaj6y50b.fsf@gitster.dls.corp.google.com
From: "Junio C Hamano" <gitster@pobox.com>
> Philip Oakley <philipoakley@iee.org> writes:
>
>> +git-send-email invokes the cc-cmd like this:
>> +
>> + $cc-cmd $patchfilename
>> +
>> +Thus the patch itself can be processed to locate appropriate email
>> address
>> +information if required.
>
> That's not even a valid command line (cc-cmd cannot be a shell
> variable name), so why bother writing it that way? Rather
We seem to be going round in circles.
Currently the --cc-cmd isn't well documented.
I was trying to use, essentially, 'cat list.txt' as the command, which
should work according to the current doc, which says nothing about
how/if the patch file is to be passed to the command.
Eric was able to make clear (*) that the code
https://github.com/git/git/blob/master/git-send-email.perl#L1602 does
essentially execute '$cc-cmd $patchfilename' where $cc-cmd is the value
of the --cc-cmd option.
This meant that my plain vanilla 'cat list.txt' command errored out.
The question are:
What should the "command" look like. (can it be a command, or does it
have to be a script??)
How should the patch/patchfile be passed - what should the documentation
guarantee?
At the moment it's the perl code that defines execution of the rather
flexible '$cc-cmd $patchfilename' command. (i.e. anything could be in
the $cc-cmd string)
>
> The program that is specified by `cc-cmd` is invoked by `git
> send-email` with the name of the patch file as an argument;
> the program can read from it and customize its output based on
> what the patch file contains.
>
> or something like that, perhaps.
>
>> +
>> +A simple solution for a basic address list is to create a 'cc-cmd'
>> file
>> +(executable) which provides a list of addressees:
>
> There is no "problem" stated here that requires your "solution". In
> fact, what problem are you solving?
As noted above, it's so that I can state a direct command as
the --cc-cmd, so that a plain text file listing cc addresses is offered
to send-email, without needing to create a script.
>
>> + #!/bin/sh
>> + echo <<\EOF
>> + person1@example.com
>> + person2@example.com
>> + EOF
>
> That is one simple and denegerate use case; if the program does not
> need any information from the patch file, it surely has an option
> not to look at it. But it is not an interesting usage.
>
> If you want to add a single example to illustrate how cc-cmd (or
> to-cmd, or anything that goes thru recipients_cmd()), you should
> have an example that reads the input and then adds a few hardcoded
> one.
>
> #!/bin/sh
> # always send it to the logger service
> echo "patchlog@example.com"
> # tell the bug tracker as necessary
> if fixes=$(sed -ne 's/^Fixes bug#\([0-9]*\)/\1/p' "$1")
> then
> echo "bugs+$fixes@example.com"
> fi
>
> or something silly like that.
>
> And this ...
>
>> +Simply, using `cat cc-cmd` as the --cc-cmd (with cc-cmd as the text
>> file
>> +of email addresses), does not work as expected as the invocation
>> becomes:
>> +
>> + $cat cc-cmd $patchfilename
>> +
>
> ... and the rest of the patch is unnecessary noise to a reader who
> read that the single argument to the program is the name of the
> patchfile, I think. You were trying to avoid the same confusion
> caused by the sketchy documentaiton, and you already "solved" that
I'm not so sure that all other readers would 'know' what went wrong if
they tried the same as I, without going through the same Q&A, hence the
desire to inform.
> problem by telling the reader what the command takes as its input.
>
>> + --cc-cmd='cat cc-cmd #'
>
> This heavily depends on the current implementation that happens to
> pass the command line string to a shell.
Not sure what effective alternative is being suggested - if its a shell
script, it'll still hit the shell.
>
--
Philip
next prev parent reply other threads:[~2015-07-20 21:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-20 18:26 [PATCH 0/3] Update send-email cc-cmd documentation Philip Oakley
2015-07-20 18:26 ` [PATCH 1/3] doc: convert send-email option headings to nouns Philip Oakley
2015-07-20 18:26 ` [PATCH 2/3] doc: send-email; expand on the meaning of 'auto-cc' Philip Oakley
2015-07-20 18:34 ` Eric Sunshine
2015-07-20 18:26 ` [PATCH 2/3] doc: send-email; expand oon " Philip Oakley
2015-07-20 18:55 ` Philip Oakley
2015-07-20 18:26 ` [PATCH 3/3] doc: give examples for send-email cc-cmd operation Philip Oakley
2015-07-20 18:50 ` Eric Sunshine
2015-07-20 19:14 ` Eric Sunshine
2015-07-20 20:26 ` Eric Sunshine
2015-07-20 19:36 ` Philip Oakley
2015-07-20 20:36 ` Eric Sunshine
2015-07-20 19:59 ` Junio C Hamano
2015-07-20 21:35 ` Philip Oakley [this message]
2015-07-20 22:37 ` Junio C Hamano
2015-07-20 22:59 ` Junio C Hamano
2015-07-21 22:48 ` Philip Oakley
2015-07-22 18:58 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=996C8C8A69844E44890D09811C57DAC8@PhilipOakley \
--to=philipoakley@iee.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sunshine@sunshineco.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).