Christian Couder [off-list ref] writes:
quoted
However, I am wondering if the current "everything on the command
line is instruction to the command" is too limiting to allow the use
of the tool both as a filter and as a tool that can work on one or
more files named on the command line. If we start from there, the
only way to later add "these arguments are names of the files to be
operated on" is to add "--file <file1> --file <file2>..." options,
which feels quite backwards as a UNIX tool.
Yeah, except that we could add for example a '-o' option that would
take a directory as argument and that would mean that the command
should operate on all the files in this directory. It would be like
the -o option of the format-patch command.
For output for which users do not know offhand what files are to be
produced, giving a single directory with -o makes tons of sense, but
for input, naming each individual file (and with help with shell
globs *) is a lot more natural UNIX tool way, I would think. "Take
everything from this directory" cannot be substitute for that, even
though the reverse (i.e. by naming the input files with "dir/*") is
true. It is not a viable replacement.
First, if you think that the command might often be used along with
format-patch,
... I am not singling out format-patch output. Any text file/stream
that has the commit log message may benefit from the "trailers" filter,
and format-patch output is merely one very obvious example. As to
the detection of the end of commit log message, the current "EOF is
where the log message ends (but we would remote trailing blank line)"
can easily be updated to "EOF or the first three-dash line".
Third, if trailers arguments are passed to the command using an
option like "-z token=value" or "-z token:value", it would be nice
to the user for consistency if the same option could be used when
passing the same arguments to "git commit" and perhaps other
commands like "git rebase", "git cherry-pick" and so on. This
means that we now have to choose carefully the name of this
option. Perhaps we can just give it a long name now like --trailer
and care later about a short name,...
Absolutely. That is a very sensible way to go.
Fourth, some users might want the command to be passed some files as
input, but they might not want the command to modify these input
files. They might prefer the command to write its ouput into another
set of output files. Maybe a syntax like cat or sed is not very well
suited for this kind of use, while having a -o option for the output
directory and a -i option for the input directory (if different from
the output dir) would be nicer.
Sure. I would expect we would require something like Perl's '-i'
(in-place rewrite) option for this sequence to really work:
git format-patch -o there -5
git that-command --options -i there/*
and without, I would expect the output to come to its standard
output.
Thanks.
On Mon, Apr 14, 2014 at 11:41 PM, Junio C Hamano [off-list ref] wrote:
Christian Couder [off-list ref] writes:
quoted
Yeah, except that we could add for example a '-o' option that would
take a directory as argument and that would mean that the command
should operate on all the files in this directory. It would be like
the -o option of the format-patch command.
For output for which users do not know offhand what files are to be
produced, giving a single directory with -o makes tons of sense, but
for input, naming each individual file (and with help with shell
globs *) is a lot more natural UNIX tool way, I would think.
Yeah, but the "git interpret-trailers" command is a special, because,
if it takes files as arguments, then it is logical that its output
would be also files and not stdout. (See also at the end of this
message.)
"Take
everything from this directory" cannot be substitute for that, even
though the reverse (i.e. by naming the input files with "dir/*") is
true. It is not a viable replacement.
quoted
First, if you think that the command might often be used along with
format-patch,
... I am not singling out format-patch output. Any text file/stream
that has the commit log message may benefit from the "trailers" filter,
and format-patch output is merely one very obvious example. As to
the detection of the end of commit log message, the current "EOF is
where the log message ends (but we would remote trailing blank line)"
can easily be updated to "EOF or the first three-dash line".
Ok, I think that it's an interesting feature anyway, so I can add it
now instead of later.
quoted
Third, if trailers arguments are passed to the command using an
option like "-z token=value" or "-z token:value", it would be nice
to the user for consistency if the same option could be used when
passing the same arguments to "git commit" and perhaps other
commands like "git rebase", "git cherry-pick" and so on. This
means that we now have to choose carefully the name of this
option. Perhaps we can just give it a long name now like --trailer
and care later about a short name,...
Absolutely. That is a very sensible way to go.
Ok, I will use "--trailer" then. As I said in my previous message,
this unfortunately means that the command will not be very user
friendly until we integrate it with other commands like "git commit"
and find a short option name that hopefully work for all the commands.
quoted
Fourth, some users might want the command to be passed some files as
input, but they might not want the command to modify these input
files. They might prefer the command to write its ouput into another
set of output files. Maybe a syntax like cat or sed is not very well
suited for this kind of use, while having a -o option for the output
directory and a -i option for the input directory (if different from
the output dir) would be nicer.
Sure. I would expect we would require something like Perl's '-i'
(in-place rewrite) option for this sequence to really work:
git format-patch -o there -5
git that-command --options -i there/*
and without, I would expect the output to come to its standard
output.
If the input comes from stdin, then I agree that the command should be
a filter, so its output should be on stdout. But if the input comes
from files given as arguments, then I would say that the command
should behave as an editor and by default it should edit its input
file inplace. Its input and output files should be different only if
it is given one or more special option,
Otherwise the example you gave:
$ git format-patch -5 --cover-letter -o +my-series/ my-topic
$ git interpret-trailers "some args" ./+my-series/0*.patch
would result in having on stdout all the patches edited by "git
interpret-trailers".
How would people could then easily send these edited patches?
Thanks,
Christian.