From: Junio C Hamano <gitster@pobox.com>
To: "Коля Гурьев" <guriev-ns@ya.ru>
Cc: Eric Sunshine <sunshine@sunshineco.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH v2] status: -i shorthand for --ignored command line option
Date: Mon, 13 Aug 2018 09:46:23 -0700 [thread overview]
Message-ID: <xmqqftzi6wps.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <a178d91c-74dd-e04a-8db3-70cd75ad6793@ya.ru> ("Коля Гурьев"'s message of "Mon, 13 Aug 2018 08:02:47 +0300")
Коля Гурьев <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.
prev parent reply other threads:[~2018-08-13 16:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqftzi6wps.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=guriev-ns@ya.ru \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).