.gitignore issue

.gitignore issue

[Alf Clement]

Hello,

I found an unexplainable behavior - see below.

best regards,
Alf

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
Adding an new line to .gitignore to filter directories.

What did you expect to happen? (Expected behavior)
I expected to see no backup_STOCKS* directory on git status.

What happened instead? (Actual behavior)
It also surpressed the backup/ directory.

What's different between what you expected and what actually happened?
When I surpress backup_STOCKS* or backup_STOCKS*/ I expect a backup/
directory still to be visible.

Anything else you want to add:
Here are the actions:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   .gitignore

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        asset_history_2025_20260114.csv
        backup_STOCKS_20260107_060326/
        backup_STOCKS_20260107_184151/
        backup_STOCKS_20260110_173702/
        backup_STOCKS_20260114_172546/
        backup_STOCKS_20260116_201409/
        backup_STOCKS_20260116_210037/
        backup_STOCKS_20260117_184437/
        backup_STOCKS_20260119_202817/
        backups/
        index.after.txt
        index.before.txt

no changes added to commit (use "git add" and/or "git commit -a")
$ echo 'backup_STOCKS*/' >>.gitignore
$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   .gitignore

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        asset_history_2025_20260114.csv
        index.after.txt
        index.before.txt
$ cat .gitignore
png/
__pycache__
mongodb.yaml
*.log
*.pdf
OLD
.vscode
ca.pem
py.pem
states/
.skylos
backup_STOCKS*/

[System Info]
git version:
git version 2.43.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC
Thu Jun  5 18:30:46 UTC 2025 x86_64
compiler info: gnuc: 13.3
libc info: glibc: 2.39
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Re: .gitignore issue

[Pushkar Singh]

Hi Alf,

This is expected behavior.
When a directory matches an ignore rule, Git stops descending into it entirely. The pattern

        backup_STOCKS*/

matches directories starting with backup_STOCKS, and once Git prunes traversal at that level, similarly prefixed paths can disappear from git status, which is why backups/ no longer shows up.

This isn’t a bug, but a result of how ignore patterns and directory pruning work.

If you want to ignore only those directories and nothing else, anchoring the pattern helps:

        /backup_STOCKS_*/

You can also verify which rule is responsible with:

        git check-ignore -v backups/

Hope that clears it up.

Best,
Pushkar

Re: .gitignore issue

[Jeff King]

On Wed, Jan 21, 2026 at 06:51:02PM +0000, Pushkar Singh wrote:

> This is expected behavior.
> When a directory matches an ignore rule, Git stops descending into it entirely. The pattern
> 
>         backup_STOCKS*/
> 
> matches directories starting with backup_STOCKS, and once Git prunes traversal at that level, similarly prefixed paths can disappear from git status, which is why backups/ no longer shows up.
> 
> This isn’t a bug, but a result of how ignore patterns and directory pruning work.

I found this explanation confusing: surely we would never match
"backups/" itself via a pattern like "backup_STOCKS*". And I'm not sure
what you mean by "similarly prefixed paths".

But what I suspect is happening here (and what you were trying to get
at) is that Git will not report an empty directory as untracked. And one
that consists only of ignored files is considered empty.

So a simpler example:

  git init
  mkdir subdir
  git status

At this point "git status" will report nothing, because there are no
files at all.

If we add a file:

  echo foo >subdir/file
  git status

Now "subdir/" is untracked (unless you use --untracked-files=all, in
which case we actually list "subdir/file" itself).

And if we ignore it like this:

  echo subdir/file >.gitignore
  git status

Now subdir/ is no longer reported. And we get the same effect with an
un-anchored top-level pattern, which also matches in subdirectories:

  echo file >.gitignore
  git status

We can't know for certain this is what's going on because Alf didn't
show us what's in the backups/ directory, but one imagines it is also
full of backup_STOCKS_* directories.

> If you want to ignore only those directories and nothing else, anchoring the pattern helps:
> 
>         /backup_STOCKS_*/
> 
> You can also verify which rule is responsible with:
> 
>         git check-ignore -v backups/

So yes, both of these are very good advice.

-Peff

Re: .gitignore issue

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Jan 21, 2026 at 06:51:02PM +0000, Pushkar Singh wrote:
>
>> This is expected behavior.
>> When a directory matches an ignore rule, Git stops descending into it entirely. The pattern
>> 
>>         backup_STOCKS*/
>> 
>> matches directories starting with backup_STOCKS, and once Git prunes traversal at that level, similarly prefixed paths can disappear from git status, which is why backups/ no longer shows up.
>> 
>> This isn’t a bug, but a result of how ignore patterns and directory pruning work.
>
> I found this explanation confusing: surely we would never match
> "backups/" itself via a pattern like "backup_STOCKS*". And I'm not sure
> what you mean by "similarly prefixed paths".

Great minds think alike.  I was writing almost identical response
about backups/ being full of backups/backup_STOCKS_{1,2,3,4} and
nothing unignored in there.

> We can't know for certain this is what's going on because Alf didn't
> show us what's in the backups/ directory, but one imagines it is also
> full of backup_STOCKS_* directories.

Thanks.