From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Elijah Newren" <newren@gmail.com>,
"Raúl Núñez de Arenas Coronado" <raulnac@gmail.com>,
git@vger.kernel.org
Subject: Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory
Date: Wed, 24 Jan 2024 13:57:54 -0500 [thread overview]
Message-ID: <20240124185754.GA21980@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqjznyhd90.fsf@gitster.g>
On Wed, Jan 24, 2024 at 09:06:51AM -0800, Junio C Hamano wrote:
> ------ >8 ----------- >8 ----------- >8 ----------- >8 ------
> Subject: ls-files: avoid the verb "deprecate" for individual options
>
> When e750951e74f updated the documentation to give greater
> visibility to the --exclude-standard option, it marked the
> `--exclude-per-directory` option as "deprecated". While it
> technically is correct that being deprecated does not necessarily
> mean it is planned to be removed later, it seems to cause confusion
> to readers, especially when we merely mean
>
> The option Y can be used to achieve the same thing as the option
> X, so to those of you who aren't familiar with either X or Y, we
> would recommend to use Y.
>
> This is especially true for `--exclude-standard` vs the combination
> of more granular `--exclude-from` and `--exclude-per-directory`
> options. It is true that one common combination of the granular
> options can be obtained by just giving the former, but that does not
> necessarily mean a more granular control is not necessary.
>
> State why we recommend looking at `--exclude-standard` when we do so
> in the description of `--exclude-per-directory`, instead of saying
> that the option is deprecated. Also, spell out the recipe to emulate
> what `--exclude-standard` does, so that the users can give it minute
> tweaks (like "not reading the global exclusion file from core.excludes").
This perfectly sums up the situation from my viewpoint. And I think the
changes you suggest not only remove the confusion over the term, they
lay out the possible options for the user much better.
The patch looks good to me, modulo one minor comment:
> diff --git c/Documentation/git-ls-files.txt w/Documentation/git-ls-files.txt
> index f65a8cd91d..93a0111cfb 100644
> --- c/Documentation/git-ls-files.txt
> +++ w/Documentation/git-ls-files.txt
> @@ -119,8 +119,10 @@ OPTIONS
>
> --exclude-per-directory=<file>::
> Read additional exclude patterns that apply only to the
> - directory and its subdirectories in <file>. Deprecated; use
> - --exclude-standard instead.
> + directory and its subdirectories in <file>. If you are
> + trying to emulate the way how Porcelain commands work,
> + using the `--exclude-standard` instead is easier and more
> + thorough.
As a native English speaker, the phrasing here is awkward to me. I'd
probably say "...emulate the way that Porcelain commands work". Or
alternatively, "emulate how Porcelain commands work".
-Peff
next prev parent reply other threads:[~2024-01-24 18:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGF1KhWNaO_TUuCPo2L_HzNnR+FnB1Q4H6_xQ2owoH+SnynzEg@mail.gmail.com>
2024-01-22 20:45 ` Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory Raúl Núñez de Arenas Coronado
2024-01-22 20:52 ` Junio C Hamano
2024-01-22 21:07 ` Raúl Núñez de Arenas Coronado
2024-01-22 21:42 ` Junio C Hamano
2024-01-23 6:08 ` Raúl Núñez de Arenas Coronado
2024-01-22 21:34 ` Jeff King
2024-01-22 21:45 ` Junio C Hamano
2024-01-22 21:59 ` Jeff King
2024-01-24 2:58 ` Elijah Newren
2024-01-24 17:06 ` Junio C Hamano
2024-01-24 18:57 ` Jeff King [this message]
2024-01-23 5:40 ` Raúl Núñez de Arenas Coronado
2024-01-24 1:09 ` Jeff King
2024-01-24 14:22 ` Raúl Núñez de Arenas Coronado
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=20240124185754.GA21980@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=raulnac@gmail.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.
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).