Jeff King <peff@xxxxxxxx> writes: > (I do still think we don't want to push it down into prefix_filename(), > because it gets used for paths and pathspecs given raw on the command > line. It does make me wonder if there are places where OPT_FILENAME() is > doing the wrong thing). To be quite honest, I had the opposite reaction ;-) At least for OPT_FILENAME() thing, I think it is well known that you should work around with "git cmd --opt ./-" if you do mean a file whose name happens to be a single dash. Teaching prefix_filename() the same trick does not look _too_ bad. There is a problem that commands that use prefix_filename() may not be prepared to read from the standard input or write to the standard output. For some such callers it may be just the matter of replacing an unconditional open() with - fd = open(filename, O_RDONLY); + if (!strcmp(filename, "-")) + fd = 0; + else + fd = open(filename, O_RDONLY); or something, but if some callers have fundamental reasons why they do not want to work with the standard input, it may make sense to treat "-" as a normal filename, and for them, blindly prefixing the leading directory name would be much better than special casing "-". So, I dunno.
