Re: Message from git reset: confusing?

Matthieu Moy [off-list ref] writes:

I was wondering what was the motivation for the output of "git merge":

You meant "git reset".

$ git reset file
file: locally modified
$ 

First a tangent.

Removing this output _when no <path> is given_ would greatly reduce the
usability of the command.

I often find myself working on something that consists of more than one
steps, and initially I decide that these would form, say, two commits A,
and B.  I first start adding the changes that are relevant to A, and my
index gradually gets closer to what A should finally look like.

But then I realize that logically commit B should come before commit A,
and it is time to "git reset" without any <path>s.  The output would let
me review the changes (this includes changes pertaining to both A and B)
to help me recall which files would contain changes that are relevant to
B.

I agree that "git reset a-single-exact-filename" could be much more
silent.  I would even say we do not even need -v in such a case.

But the thing is, that is a very narrow special case.  The parameter the
command takes is not _a file_, but is a set of pathspecs, and I would
imagine that when you are in a situation similar to what I just described
in a larger project, you would appreciate the same reminder of modified
paths when you run the command like this:

    $ git reset include/ arch/x86/

I wouldn't oppose to a patch that squelches the output when all pathspecs
given from the command line _exactly_ name existing paths, but I tend to
think that it would be usability regression if you do not show any output
in a case like the last example.