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

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

[Nicholas Guriev]

This short option saves the number of keys to press for the
typically git-status command.
---
I already sent the patch here, but it doesn't seem reached to the
list. So I send the email (now with DKIM) again and apologize if you
get this twice.

 builtin/commit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 158e3f8..44829b9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1319,7 +1319,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 		  N_("mode"),
 		  N_("show untracked files, optional modes: all, normal, no. (Default: all)"),
 		  PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
-		{ OPTION_STRING, 0, "ignored", &ignored_arg,
+		{ OPTION_STRING, 'i', "ignored", &ignored_arg,
 		  N_("mode"),
 		  N_("show ignored files, optional modes: traditional, matching, no. (Default: traditional)"),
 		  PARSE_OPT_OPTARG, NULL, (intptr_t)"traditional" },
-- 
2.7.4

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

[Eric Sunshine]

Thanks for the submission. A few comments below...

On Wed, Aug 8, 2018 at 2:48 AM Nicholas Guriev <guriev-ns@ya.ru> wrote:
> This short option saves the number of keys to press for the
> typically git-status command.
> ---

Your sign-off is missing. See Documentation/SubmittingPatches.

It's clear that a short name would be helpful to you, but you may need
to work harder to convince others that it makes sense to squat an a
short option name like 'i'. One argument you might use in the commit
message in support of adding a short name to --ignored is that the
related option --untracked-files already has a short name (-u).

>  builtin/commit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This patch neglects to update the documentation for git-status in
Documentation/git-status.txt. It will need to do so if this change is
ever to be accepted.

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

[Nicholas Guriev]

It allows for uniformity with the --untracked-files option. Also
the new short flag saves the number of keys to press for the
typically git-status command.

Signed-off-by: Nicholas Guriev <guriev-ns@ya.ru>
---
 Documentation/git-status.txt | 1 +
 builtin/commit.c             | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index d9f422d..cce352a 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -97,6 +97,7 @@ configuration variable documented in linkgit:git-config[1].
 	(and suppresses the output of submodule summaries when the config option
 	`status.submoduleSummary` is set).
 
+-i[<mode>]::
 --ignored[=<mode>]::
 	Show ignored files as well.
 +
diff --git a/builtin/commit.c b/builtin/commit.c
index 158e3f8..44829b9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1319,7 +1319,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 		  N_("mode"),
 		  N_("show untracked files, optional modes: all, normal, no. (Default: all)"),
 		  PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
-		{ OPTION_STRING, 0, "ignored", &ignored_arg,
+		{ OPTION_STRING, 'i', "ignored", &ignored_arg,
 		  N_("mode"),
 		  N_("show ignored files, optional modes: traditional, matching, no. (Default: traditional)"),
 		  PARSE_OPT_OPTARG, NULL, (intptr_t)"traditional" },
-- 
2.7.4

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

[Junio C Hamano]

Nicholas Guriev <guriev-ns@ya.ru> writes:

> It allows for uniformity with the --untracked-files option. Also
> the new short flag saves the number of keys to press for the
> typically git-status command.

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.  

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.

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

[Коля Гурьев]

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, I suggest this shortening based on first letter of
the --ignored option because git-status and git-commit are different
commands and it's more obvious shortening.

> 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. I've discovered that I type this option quite
frequently, and I hope my case may help others.

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

[Junio C Hamano]

Коля Гурьев <guriev-ns@ya.ru> writes:

> 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.

>> 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.