On Fri, Jan 27, 2017 at 10:30:48AM -0800, Junio C Hamano wrote: > > 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. I think a lot of the documentation uses <paths> to refer to pathspecs (e.g., git-log(1), git-diff(1), etc). As long as we're consistent with that convention, I don't think it's that big a deal. This spot needs a specific mention because it violates the convention. I don't know if the are other spots where it might be unclear, but I think we're probably better to tighten those as they come up, rather than switch to saying "<pathspecs>" everywhere. That's outside the scope of this series, though, I would think. -Peff