git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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/

      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).