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

Коля Гурьев [off-list ref] writes:

09.08.2018 18:44, Junio C Hamano пишет:

quoted

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.

quoted

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.