Junio C Hamano <gitster@xxxxxxxxx> 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 -- 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