Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 2/2 (v3)] reset: make the output more user-friendly.

From: Matthieu Moy <hidden>
Date: 2016-06-15 22:47:17

Junio C Hamano [off-list ref] writes:
Thanks.  Will queue.
Thanks,
However, I'd change the justification.
Fine with me.
The output from reset in question is merely an informative side effect, as
opposed to what you actively ask "git diff" to give as its primary output.
As such, your "consistency" argument is pretty weak.  There is no reason
to expect that the informative message to resemble one particular format
(namely, --name-status) and not another (e.g. --stat or --name-only),
I agree that chosing --name-status over, like, --stat is rather
arbitrary. But Git has IMHO far too many languages for talking about
changes (--stat, --name-status, 'git status' itself, the 'git ls-files
-t' that I just discovered, and this 'bla: locally modified').
Reducing the number of formats by one is a good thing to me.
Informative output from "git checkout $branch" when there are local
changes is a much better precedent to refer to.
Yes.
I am somewhat inclined to suggest that we should drop the new "Unstaged
changes after ..." message, though.
I've thought about this too. The new format already looks much less
like an error message, which was really the problem I was solving. But
one advantage of the message contains two relevant informations:
"unstaged" and "after".

Intuitively, I would have thought that "git reset" was reporting what
it was doing, as it was doing it. So to me (before experimenting a bit
more and looking at the source code),

M	foo.txt
M	bar.txt

would mean "I've just reseted foo.txt and bar.txt, which were locally
modified", while actually "git reset" can very well show this message
after reseting only foo.txt, just informing the user that bar.txt is
also modified. So, at least to me, the semantics was very unclear, and
while I would have understood immediately with the one-liner message.

In short: no strong objection to remove this message, but to me it is
usefull.

-- 
Matthieu
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help