Matthieu Moy <Matthieu.Moy@xxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html