Joey Hess [off-list ref] writes:
quoted
Do you make any promises that %p is a seekable file?
Yes, %p is a regular file and so is seekable, statable, etc.
I wonder if we prefer not to make this customizable (i.e. not having
to use'%p'). Unlike '%f' that is optional, smudgeTo and cleanFrom
"filters" are not filters and MUST read from the path given and not
from any other paths.
A misconfigured smudgeTo filter that uses %f would overwrite a wrong
file when used with checkout-index --prefix=<there>, right?
The only thing '%p' buys is that a "filter" could be written in such
a way that takes the pathname at arbitrary place on the command
line. A command line that does not have '%p' anywhere is invalid,
which is quite different from how '%f' behaves.
Would an interface that always appends the pathname at the end of
the command line string work? E.g.
[filter "foo"] smugeToFile = cmd --from-file
would run "cmd --from-file PATH" when Git wants it to read from
PATH, and
[filter "bar"] smugeToFile = sh -c 'cmd --from-file="$0"'
would run
sh -c 'cmd --from-file="$0"' PATH
which in turn becomes 'cmd --from-file=PATH'.
Or something like that.
Junio C Hamano wrote:
Would an interface that always appends the pathname at the end of
the command line string work?
I'm ok with this, and like getting rid of %p as it's not distinguishable
from %f without reading the documentation.
The sh -c trick can of course be used if some other ordering of
parameters is needed. Probably anything using this interface is gonna be
implemented with the interface in mind from the beginning and won't need
such a trick.
--
see shy jo
Junio C Hamano wrote:
Would an interface that always appends the pathname at the end of
the command line string work?
One problem with this is that "appends" is subtly unclear in this case.
With the example of smugeToFile = cmd --to-file
it seems that a space should be added by git before the filename.
On the other handle, consider smugeToFile = cmd --to-file=
here a space is not wanted before the filename.
So, either a space is automatically included before the filename
and the second example breaks, or no space is included, and
to make the first example work would need careful inclusion of the
trailing space with quoting to prevent it being elided
eg, smugeToFile = "cmd --to-file "
%p does avoid this ambiguity. But as Junio noted, %p is mandatory in the
command for it to possibly work. Git could refuse to use smugeToFile = cmd
as not containing a %p and so not possibly being able to work.
Or we could pick one of the two methods of appending the file
(I prefer not including a space before it as more flexible), and
anything using this interface would need to design its command line
parsing with this interface in mind, and would probably choose to use
--to-file=foo rather than --to-file foo.
--
see shy jo