Re: Bug: git add does not process gitignore properly

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2023, 22:19 UTC
Message-ID: <xmqqjzvs7bbr.fsf@gitster.g>
In-Reply-To: <d748b4bb-6be2-4936-04d0-f0edcf228dfb@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 7 quoted lines

> 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/