From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
David C Black <david.black@doulos.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Bug: git add does not process gitignore properly
Date: Sat, 24 Jun 2023 15:19:20 -0700 [thread overview]
Message-ID: <xmqqjzvs7bbr.fsf@gitster.g> (raw)
In-Reply-To: d748b4bb-6be2-4936-04d0-f0edcf228dfb@gmail.com
Phillip Wood <phillip.wood123@gmail.com> writes:
> I think the usual way around this is to use patterns like
>
> /extern/*
> !/extern/bin/
> !/extern/ABOUT.md
>
> see the example on the gitignore man page.
Thanks for a very good suggestion.
The behaviour may be somewhat counter-intuitive, especially when you
have "/extern/" followed by "!/extern/blah" in the same file. The
original rationale for this was because the behaviour becomes
consistent between the cases where
(1) these two patterns appear in the same top-level .gitignore
file, and
(2) "/extern/" is in the top-level .gitignore file and "!/bin/" is
in ".gitignore" file in the "extern/" directory
which ought to be the moral equivalents.
There have been at least two attempts to change this, but without
much success.
- 57534ee7 (dir.c: don't exclude whole dir prematurely if neg
pattern may match, 2015-09-21) tried but it caused breakages
reported on the list [*1*, *2*] and got reverted at 8c722360
(Revert "dir.c: don't exclude whole dir prematurely if neg
pattern may match", 2016-01-08).
- 5e57f9c3 (Merge branch 'nd/exclusion-regression-fix', 2016-02-24)
was a merge of another attempt, which again had to be reverted at
5cee3493 (Revert "Merge branch 'nd/exclusion-regression-fix'",
2016-03-18).
It is dubious if it is worth making another attempt to change it.
"Fixing" this and still keeping consistency between the two ways to
spell the same pair of rules would mean that even "/extern/" in the
".gitignore" file in a higher level tells us not to bother with the
"extern" directory, we would have to look for "extern/.gitignore"
just in case it unignores something, which would probably make it
unacceptably costly. It would be quite a backward incompatible
change, too.
[References]
*1* Git 2.7.0 gitignore behaviour regression:
https://lore.kernel.org/git/20160107234455.GB265296@vauxhall.crustytoothpaste.net/
*2* Behavior change in 2.7.0: With core.sparseCheckout some files have
the skip-worktree bit set after a checkout.:
https://lore.kernel.org/git/trinity-5caa2985-5cf1-453b-9a9e-bcce057f8615-1452249323061@3capp-gmx-bs51/
prev parent reply other threads:[~2023-06-24 22:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 19:38 Bug: git add does not process gitignore properly David C Black
2023-06-23 22:07 ` Eric Sunshine
2023-06-24 10:13 ` Phillip Wood
2023-06-24 22:19 ` 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=xmqqjzvs7bbr.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=david.black@doulos.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@gmail.com \
--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.
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).