From: Junio C Hamano <gitster@pobox.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Git Mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] Doc: Mention core.excludesFile in "man git-clean"
Date: Wed, 23 May 2018 10:48:15 +0900 [thread overview]
Message-ID: <xmqqsh6jw3a8.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <alpine.LFD.2.21.1805220345150.749@localhost.localdomain> (Robert P. J. Day's message of "Tue, 22 May 2018 03:48:13 -0400 (EDT)")
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
> Add a reference to the configuration setting "core.excludesFile" to
> the man page for git-clean.
>
> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
>
> ---
I understand that you are trying to reduce the source of the
confusion you felt, which comes from mentioning only per-directory
.gitignore and per-repository info/exclude, but I am not sure if the
proposed solution is a good one that learned from our past mistakes.
Wouldn't it make more sense to _avoid_ appearing as if we are giving
a complete list and refer those who want a single authoritative list
to the source? For example
In addition to those found in standard places for exclude
patterns such as `.gitignore` (cf. linkgit:gitignore[5]),
also consider these patterns...
After all, having an incomplete list and not hinting that it is
incomplete is what made you react to the current description. It is
unlikely that we stop treating `.gitignore` as one of the standard
places, so phrasing like above will have a lot smaller chance to go
stale, even accounting for the possibility that we will grow Git
over time and the standard parttern sources may be updated in the
future.
>
> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> index 03056dad0..449cbc2af 100644
> --- a/Documentation/git-clean.txt
> +++ b/Documentation/git-clean.txt
> @@ -55,13 +55,15 @@ OPTIONS
>
> -e <pattern>::
> --exclude=<pattern>::
> - In addition to those found in .gitignore (per directory) and
> - $GIT_DIR/info/exclude, also consider these patterns to be in the
> - set of the ignore rules in effect.
> + In addition to patterns found in any of .gitignore (per directory),
> + $GIT_DIR/info/exclude and the exclude file specified by the
> + configuration variable core.excludesFile, also consider these
> + patterns to be in the set of the ignore rules in effect.
>
> -x::
> Don't use the standard ignore rules read from .gitignore (per
> - directory) and $GIT_DIR/info/exclude, but do still use the ignore
> + directory), $GIT_DIR/info/exclude and the exclude file specified
> + by core.excludesFile, but do still use the ignore
> rules given with `-e` options. This allows removing all untracked
> files, including build products. This can be used (possibly in
> conjunction with 'git reset') to create a pristine
prev parent reply other threads:[~2018-05-23 1:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 7:48 [PATCH] Doc: Mention core.excludesFile in "man git-clean" Robert P. J. Day
2018-05-23 1:48 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqsh6jw3a8.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=rpjday@crashcourse.ca \
/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.
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 NNTP newsgroup(s).