git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: .gitignore sub-dir exclusions not overriding '*'

From
Duy Nguyen <pclouds@gmail.com>
Date
Nov 20, 2014, 01:26 UTC
Message-ID
<CACsJy8Cfg5eEoJb3zvPKoTjC8ZX-2ptggTUo_6yFz+q+-rqAnA@mail.gmail.com>
In-Reply-To
<20141119234136.GA53731@tower.spodhuis.org>

On Thu, Nov 20, 2014 at 6:41 AM, Phil Pennock <phil-gitml@phil.spodhuis.org> wrote:

Show 35 quoted lines
> On 2014-11-19 at 16:48 +0700, Duy Nguyen wrote:
>> On Wed, Nov 19, 2014 at 10:40 AM, Phil Pennock
>> <phil-gitml@phil.spodhuis.org> wrote:
>> > Expected to work as .gitignore in top-level of repo:
>> >
>> >     *
>> >     !**/*.asc
>> >     !.gitignore
>> >
>>
>> gitignore man page has this "It is not possible to re-include a file
>> if a parent directory of that file is excluded". In this case,
>> directory "foo" is ignored by "*". Although it makes sense for this
>> particular case to re-include something in foo because we can clearly
>> see there are rules to re-include. It's on my todo list, but I don't
>> know when it will be implemented.
>
> Thanks for this and the patches and discussion which follow.
>
> I didn't cover it in my report, but one of the scenarios I tried was to
> explicitly re-include directories, to make them candidates again, and
> either use directory-matching patterns in the top-level .gitignore or to
> use per-directory .gitignore to handle those directories.
>
> Looking fresh today, I see that I failed to compare baseline behaviour
> without a .gitignore when using `git status` as a baseline for
> comparison.  So a .gitignore like this:
>
>     *
>     !*/
>     !*.asc
>
> appeared to not work; even within the `foo/` sub-directory, `git status`
> shows no candidates for inclusion.  But this is true even without a
> .gitignore.  *sigh*

I should have read this mail before replying to Junio in the other email :( Yeah the "!*/" would re-include dirs back. I'm not sure if there are any side effects by doing this, no time to think about this yet. Maybe we can put this in the example section in gitignore man page with more explanation.

Show 16 quoted lines
> In fact, it looks like the simple three lines above work, without any
> .gitignore in sub-directories.
>
> The behaviour which confused me between this simplified test-case and
> the original was that `git status` shows files in the top-level
> directory which are untracked, and in untracked files sub-directories
> where some other file in that directory is already tracked, but if no
> file in the sub-directory is already tracked, then `git status` does not
> report the files for inclusion, even if the cwd is inside that
> directory.
>
> I tied myself in knots trying to avoid adding unencrypted files to the
> repo.
>
> Thanks,
> -Phil
-- 
Duy
Previous: Phil Pennock
Message 7 of 7 in “.gitignore sub-dir exclusions not overriding '*'”
  1. Phil PennockNov 19, 2014
  2. Duy NguyenNov 19, 2014
  3. dir.c: allow re-include after a dir is excluded in some casesNguyễn Thái Ngọc Duy, Nov 19, 2014
  4. Junio C HamanoNov 19, 2014
  5. Duy NguyenNov 20, 2014
  6. Phil PennockNov 19, 2014
  7. Duy NguyenNov 20, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.