git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Matthieu Moy <matthieu.moy@imag.fr>
Date
Aug 22, 2009, 07:52 UTC
Message-ID
<vpq8whc8euu.fsf@bauges.imag.fr>
In-Reply-To
<7v3a7k767j.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thanks.  Will queue.
Thanks,
> However, I'd change the justification.
Fine with me.
Show 5 quoted lines
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 17 of 20 in “Message from git reset: confusing?”
  1. Matthieu MoyAug 5, 2009
  2. Junio C HamanoAug 5, 2009
  3. Avery PennarunAug 5, 2009
  4. John TapsellAug 5, 2009
  5. Sverre RabbelierAug 5, 2009
  6. Matthieu MoyAug 6, 2009
  7. Junio C HamanoAug 6, 2009
  8. 1/2 Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN.Matthieu Moy, Aug 7, 2009
  9. 2/2 reset: make the output more user-friendly.Matthieu Moy, Aug 7, 2009
  10. Junio C HamanoAug 7, 2009
  11. Matthieu MoyAug 8, 2009
  12. Matthieu MoyAug 17, 2009
  13. Junio C HamanoAug 17, 2009
  14. 1/2 Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN.Matthieu Moy, Aug 21, 2009
  15. 2/2 reset: make the output more user-friendly.Matthieu Moy, Aug 21, 2009
  16. Junio C HamanoAug 22, 2009
  17. Matthieu MoyAug 22, 2009
  18. Junio C HamanoAug 23, 2009
  19. Matthieu MoyAug 23, 2009
  20. Reece DunnAug 23, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.