{"thread":{"id":"64846","subject":"Re: .gitignore issue","startedAt":"2026-01-21T18:51:06Z","lastAt":"2026-01-21T21:09:43Z","messageCount":3,"participants":["Pushkar Singh","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"534374","messageId":"SL2P216MB1885CE309BDBA65860D8762FA296A@SL2P216MB1885.KORP216.PROD.OUTLOOK.COM","threadId":"64846","inReplyTo":null,"subject":"Re: .gitignore issue","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-01-21T18:51:02Z","receivedAt":"2026-01-21T18:51:06Z","isPatch":false,"sender":{"key":"pushkarkumarsingh1970@gmail.com","avatar":"https://avatars.githubusercontent.com/u/173247767?v=4"},"body":"Hi Alf,\n\nThis is expected behavior.\nWhen a directory matches an ignore rule, Git stops descending into it entirely. The pattern\n\n        backup_STOCKS*/\n\nmatches 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.\n\nThis isn’t a bug, but a result of how ignore patterns and directory pruning work.\n\nIf you want to ignore only those directories and nothing else, anchoring the pattern helps:\n\n        /backup_STOCKS_*/\n\nYou can also verify which rule is responsible with:\n\n        git check-ignore -v backups/\n\nHope that clears it up.\n\nBest,\nPushkar"},{"id":"534385","messageId":"20260121210312.GA723458@coredump.intra.peff.net","threadId":"64846","inReplyTo":"SL2P216MB1885CE309BDBA65860D8762FA296A@SL2P216MB1885.KORP216.PROD.OUTLOOK.COM","subject":"Re: .gitignore issue","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-01-21T21:03:12Z","receivedAt":"2026-01-21T21:03:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 21, 2026 at 06:51:02PM +0000, Pushkar Singh wrote:\n\n> This is expected behavior.\n> When a directory matches an ignore rule, Git stops descending into it entirely. The pattern\n> \n>         backup_STOCKS*/\n> \n> 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.\n> \n> This isn’t a bug, but a result of how ignore patterns and directory pruning work.\n\nI found this explanation confusing: surely we would never match\n\"backups/\" itself via a pattern like \"backup_STOCKS*\". And I'm not sure\nwhat you mean by \"similarly prefixed paths\".\n\nBut what I suspect is happening here (and what you were trying to get\nat) is that Git will not report an empty directory as untracked. And one\nthat consists only of ignored files is considered empty.\n\nSo a simpler example:\n\n  git init\n  mkdir subdir\n  git status\n\nAt this point \"git status\" will report nothing, because there are no\nfiles at all.\n\nIf we add a file:\n\n  echo foo >subdir/file\n  git status\n\nNow \"subdir/\" is untracked (unless you use --untracked-files=all, in\nwhich case we actually list \"subdir/file\" itself).\n\nAnd if we ignore it like this:\n\n  echo subdir/file >.gitignore\n  git status\n\nNow subdir/ is no longer reported. And we get the same effect with an\nun-anchored top-level pattern, which also matches in subdirectories:\n\n  echo file >.gitignore\n  git status\n\nWe can't know for certain this is what's going on because Alf didn't\nshow us what's in the backups/ directory, but one imagines it is also\nfull of backup_STOCKS_* directories.\n\n> If you want to ignore only those directories and nothing else, anchoring the pattern helps:\n> \n>         /backup_STOCKS_*/\n> \n> You can also verify which rule is responsible with:\n> \n>         git check-ignore -v backups/\n\nSo yes, both of these are very good advice.\n\n-Peff\n"},{"id":"534389","messageId":"xmqq343ysmem.fsf@gitster.g","threadId":"64846","inReplyTo":"20260121210312.GA723458@coredump.intra.peff.net","subject":"Re: .gitignore issue","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-01-21T21:09:37Z","receivedAt":"2026-01-21T21:09:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Jan 21, 2026 at 06:51:02PM +0000, Pushkar Singh wrote:\n>\n>> This is expected behavior.\n>> When a directory matches an ignore rule, Git stops descending into it entirely. The pattern\n>> \n>>         backup_STOCKS*/\n>> \n>> 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.\n>> \n>> This isn’t a bug, but a result of how ignore patterns and directory pruning work.\n>\n> I found this explanation confusing: surely we would never match\n> \"backups/\" itself via a pattern like \"backup_STOCKS*\". And I'm not sure\n> what you mean by \"similarly prefixed paths\".\n\nGreat minds think alike.  I was writing almost identical response\nabout backups/ being full of backups/backup_STOCKS_{1,2,3,4} and\nnothing unignored in there.\n\n> We can't know for certain this is what's going on because Alf didn't\n> show us what's in the backups/ directory, but one imagines it is also\n> full of backup_STOCKS_* directories.\n\nThanks.\n"}]}