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

Re: [PATCH v2] status: -i shorthand for --ignored command line option

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 13, 2018, 16:46 UTC
Message-ID
<xmqqftzi6wps.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<a178d91c-74dd-e04a-8db3-70cd75ad6793@ya.ru>
Коля Гурьев <guriev-ns@ya.ru> writes:
Show 8 quoted lines
> 09.08.2018 18:44, Junio C Hamano пишет:
>> Unlike "-u', "-i" is supported by "git commit" which shares the
>> underlying implementation, and that is the historical reason why we
>> never had "-i" shorthand, I think.  
>
> git-commit supports the -u flag, its meaning is the same as for
> git-status. Although the -i flag might be confused with the --include
> option of git-commit,...

Yes, I was describing a historical perspective on the reason why "-u" was there but "-i" was not. Since it is merely historical that 'status' was a mere synonym to 'commit --dry-run', which no longer is the case, that no longer is a reason not to have "status -i".

That is why the paragraph you are responding to in my message exists.

Show 8 quoted lines
>> While I do understand why sometimes "-u" is useful, especially
>> "-uno", to help those whose .gitignore is not managed as well as it
>> should be, I am not sure why a "typical git-status" invocation would
>> ask for "--ignored" that often to require such a short-hand.
>
> The --ignored option is often used for opposing purposes, to show all
> changes in working directory regardless of .gitignore files which may be
> written sloppy.

That's not "sloppy" but "too tightly", I think, and you won't get "changes" to them (only the presence of them).

I know a user can view more paths with "git status --ignored" in the output than without the option, and it may sometimes be interesting (after all, that is why we have the option in the first place), but I am trying to find out why a user needs to constantly asking for "--ignored" (otherwise there is no point adding a short-and-sweet "-i").

"git status -u" is not by itself a useful tool to "hide" the sloppyness of the .gitignore patterns, as "git status" by default acts the same as "git status -unormal" does to remind you that you forgot to list a pattern to catch build artifacts, and the user who wants to stay sloppy needs to work on it by saying something like "git status -uno". The short-hand does not encourage people to be sloppy too much. I am hesitant to add a short-hand that is too convenient and encourages people being sloppy (or leaving a too tight list of exclude patterns and not fixing) and wondering if "git status -i" alone, without forcing users to type a bit more (like "-uno" as opposed to "-u" alone), is such a short-hand that helps undisciplined use of the tool. That is why I am asking why a "typical git-status" invocation ask for "--ignored" that often to require such a short-hand.

Previous: Коля Гурьев
Message 6 of 6 in “status: -i shorthand for --ignored command line option”
  1. status: -i shorthand for --ignored command line optionNicholas Guriev, Aug 8, 2018
  2. Eric SunshineAug 8, 2018
  3. status: -i shorthand for --ignored command line optionNicholas Guriev, Aug 9, 2018
  4. Junio C HamanoAug 9, 2018
  5. status: -i shorthand for --ignored command line optionКоля Гурьев, Aug 13, 2018
  6. Junio C HamanoAug 13, 2018

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.