Jeff King <peff@xxxxxxxx> writes: > - a way to independently specify the source pathspec and the > output-limiting pathspec. This is a cheaper version of the one > above, where you could look at a subset of the tree a sources, but > limit the set of shown paths even further. It's not conceptually > that difficult, but syntactically it gets weird since you have two > lists of pathspecs on the command-line. Yes, the pathspec has always been input limiter and I think we have discussed adding separate output limiter from time to time, but nothing has happened. Back in the scripted porcelain days, it would conceptually have been simpler and cleaner, as you probably would run "diff-tree --raw" with no (or "input") pathspec, filter its output with "output" pathspec, and then convert the raw diff to a patch ( we used to have such a filter, before we gave the -p option to all three "diff" family backends). Introducing an option to say "Pretend as if the system supported output pathspec, and use the pathspec as such, without any input pathspec" feels like a dirty hack compared to conceptual purity of having two separate sets, and having to run without any input pathspec may not be usable in truly large project, but I suspect it may be good enough for most people (i.e. your "first one" that wouldn't be too hard). I am not sure if I like it, though X-<. >> ``` >> git diff --follow master...topic -- ZPay/ZPayClient.hpp >> ``` > > So yes, that does work, and is why I added the "(clean)" qualifier > above. It behaves like the "-C -C -C" I proposed. But the fact that it > does so is entirely accidental. What happens is this: I am kinda surprised that "diff" gets affected by "--follow" (I knew that the command line parser would take that option meant for "log" family without complaining) at all.
