Re: [PATCH 3/3] doc: give examples for send-email cc-cmd operation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Junio C Hamano" <gitster@xxxxxxxxx>
Philip Oakley <philipoakley@xxxxxxx> 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@xxxxxxxxxxx
+ person2@xxxxxxxxxxx
+ 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@xxxxxxxxxxx"
# tell the bug tracker as necessary
if fixes=$(sed -ne 's/^Fixes bug#\([0-9]*\)/\1/p' "$1")
       then
echo "bugs+$fixes@xxxxxxxxxxx"
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]