Taylor Blau <me@xxxxxxxxxxxx> writes:
> Then you can see `-G` has the effect of limiting the output of 'git
> diff' to just those file(s) whose diff matches the regular expression
> given to `-G`, like so:
>
> $ git -C repo diff --stat HEAD^
> a | 1 +
> b | 1 +
> 2 files changed, 2 insertions(+)
> $ git -C repo diff --stat HEAD^ -G a
> a | 1 +
> 1 file changed, 1 insertion(+)
> $ git -C repo diff --stat HEAD^ -G b
> b | 1 +
> 1 file changed, 1 insertion(+)
All true.
As this feature is primarily designed to help "git log" to choose
which commit to show and which commit to omit in its output, readers
would not appreciate the usefulness of the feature, when shown in
the context of "git diff".
Even more puzzling is how the "--full-diff" option works in
combination with "-G" or "-S" (or --diff-filter=... for that
matter)..
They make perfect sense as ingredients of a mechanism to choose
which commit to show in the context of "git log", but their value is
not immediately apparent in the context of "git diff". Continuing
with your example [*1*], comparing what these two do would be
illuminating:
$ git -C repo diff --full-diff --stat -G b HEAD^
$ git -C repo diff --full-diff --stat -G c HEAD^
The former should show changes to both a and b, and the latter
should show nothing.
While the way how each of these behaves makes perfect sense at the
logical level, it would be very puzzling why anybody may even want
to use such a feature in the first place. Until you realize that
comparing the previous commit and the current state (which happens
to be identical to the current commit) is more or less a degenerated
form of running "log -n <n> HEAD" with <n> set to 1, that is.
[Footnote]
*1* By the way, as an experienced mentor, avoid giving a command
line example that has dashed options after revs and paths. It
may happen to do what you intended, but is confusing to readers.
