Jeff King <p...@peff.net> writes: > A few minor suggestions: > >> +--stdin:: >> + Instead of taking list of paths from the command line, >> + read list of paths from the standard input. Paths are >> + separated by LF (i.e. one path per line) by default. >> + >> +-z:: >> + Only meaningful with `--stdin`; paths are separated with >> + NUL character instead of LF. > > Is it worth clarifying that these are paths, not pathspecs? The word > "paths" is used to refer to the pathspecs on the command-line elsewhere > in the document.
If the code forces literal pathspecs, then what the user feeds to the command is no longer pathspecs from the user's point of view, and I agree that the distinction is important. If the remainder of the documentation is loose in terminology and the reason why we were able to get away with it was because we consistently used "paths" when we meant "pathspec", these existing mention of "paths" have to be tightened, either in this patch or a preparatory step patch before this one, because the addition of "this thing reads paths not pathspecs" is what makes them ambiguous. Thanks. I re-read the part of the code that reads and unquotes as necessary in the patch and they looked correct.
