* [PATCH] status: -i shorthand for --ignored command line option [not found] <20180804181539.29536-1-guriev-ns@ya.ru> @ 2018-08-08 6:39 ` Nicholas Guriev 2018-08-08 7:34 ` Eric Sunshine 0 siblings, 1 reply; 6+ messages in thread From: Nicholas Guriev @ 2018-08-08 6:39 UTC (permalink / raw) To: git; +Cc: 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] status: -i shorthand for --ignored command line option 2018-08-08 6:39 ` [PATCH] status: -i shorthand for --ignored command line option Nicholas Guriev @ 2018-08-08 7:34 ` Eric Sunshine 2018-08-09 6:21 ` [PATCH v2] " Nicholas Guriev 0 siblings, 1 reply; 6+ messages in thread From: Eric Sunshine @ 2018-08-08 7:34 UTC (permalink / raw) To: guriev-ns; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] status: -i shorthand for --ignored command line option 2018-08-08 7:34 ` Eric Sunshine @ 2018-08-09 6:21 ` Nicholas Guriev 2018-08-09 15:44 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Nicholas Guriev @ 2018-08-09 6:21 UTC (permalink / raw) To: Eric Sunshine; +Cc: Nicholas Guriev, Git List 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] status: -i shorthand for --ignored command line option 2018-08-09 6:21 ` [PATCH v2] " Nicholas Guriev @ 2018-08-09 15:44 ` Junio C Hamano 2018-08-13 5:02 ` Коля Гурьев 0 siblings, 1 reply; 6+ messages in thread From: Junio C Hamano @ 2018-08-09 15:44 UTC (permalink / raw) To: Nicholas Guriev; +Cc: Eric Sunshine, Git List 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] status: -i shorthand for --ignored command line option 2018-08-09 15:44 ` Junio C Hamano @ 2018-08-13 5:02 ` Коля Гурьев 2018-08-13 16:46 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Коля Гурьев @ 2018-08-13 5:02 UTC (permalink / raw) To: Junio C Hamano; +Cc: Eric Sunshine, Git List 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] status: -i shorthand for --ignored command line option 2018-08-13 5:02 ` Коля Гурьев @ 2018-08-13 16:46 ` Junio C Hamano 0 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2018-08-13 16:46 UTC (permalink / raw) To: Коля Гурьев Cc: Eric Sunshine, Git List Коля Гурьев <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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-08-13 16:46 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20180804181539.29536-1-guriev-ns@ya.ru> 2018-08-08 6:39 ` [PATCH] status: -i shorthand for --ignored command line option Nicholas Guriev 2018-08-08 7:34 ` Eric Sunshine 2018-08-09 6:21 ` [PATCH v2] " Nicholas Guriev 2018-08-09 15:44 ` Junio C Hamano 2018-08-13 5:02 ` Коля Гурьев 2018-08-13 16:46 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).