From: Matthieu Moy <Matthieu.Moy@imag.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2 (v3)] reset: make the output more user-friendly.
Date: Sat, 22 Aug 2009 09:52:41 +0200 [thread overview]
Message-ID: <vpq8whc8euu.fsf@bauges.imag.fr> (raw)
In-Reply-To: <7v3a7k767j.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Fri\, 21 Aug 2009 22\:44\:48 -0700")
Junio C Hamano <gitster@pobox.com> 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
next prev parent reply other threads:[~2009-08-22 7:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-05 15:25 Message from git reset: confusing? Matthieu Moy
2009-08-05 17:21 ` Junio C Hamano
2009-08-05 17:42 ` Avery Pennarun
2009-08-05 18:07 ` John Tapsell
2009-08-05 18:25 ` Sverre Rabbelier
2009-08-06 9:42 ` Matthieu Moy
2009-08-06 19:21 ` Junio C Hamano
2009-08-07 20:24 ` [PATCH 1/2] Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN Matthieu Moy
2009-08-07 20:24 ` [PATCH 2/2 (v2)] reset: make the output more user-friendly Matthieu Moy
2009-08-07 21:20 ` Junio C Hamano
2009-08-08 7:44 ` Matthieu Moy
2009-08-17 17:31 ` Matthieu Moy
2009-08-17 19:50 ` Junio C Hamano
2009-08-21 8:57 ` [PATCH 1/2] Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN Matthieu Moy
2009-08-21 8:57 ` [PATCH 2/2 (v3)] reset: make the output more user-friendly Matthieu Moy
2009-08-22 5:44 ` Junio C Hamano
2009-08-22 7:52 ` Matthieu Moy [this message]
2009-08-23 2:33 ` Junio C Hamano
2009-08-23 10:42 ` Matthieu Moy
2009-08-23 11:45 ` Reece Dunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpq8whc8euu.fsf@bauges.imag.fr \
--to=matthieu.moy@imag.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.