# Is Git Add Supposed to Work Like This (git 2.50)? 9 messages from 2025-09-07 to 2025-09-09. Participants: Jon Forrest, K Jayatheerth, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/64101 ## Jon Forrest, 2025-09-07 02:02 Subject: Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: <63045080-74d6-4835-9d9c-4d3558acdbfb@gmail.com> URL: https://gitlist.dev/e/63045080-74d6-4835-9d9c-4d3558acdbfb%40gmail.com ``` (Linux fedora 6.16.4-200.fc42.x86_64) Let's say I have the file "x" in my working directory, but not "bogus_file". If I run git add x bogus_file I get fatal: pathspec 'bogus_file' did not match any files This is what I expect. However, if I look at what's in the index, "x" doesn't appear. The same thing happens if I specify 15 valid files followed by 1 invalid file. Apparently the presence of even 1 invalid file invalidates the whole 'git add' command, no matter how many valid files are included. Is this deliberate? Cordially, Jon Forrest ``` ## K Jayatheerth, 2025-09-07 08:10 Subject: Re Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: <20250907081014.17466-1-jayatheerthkulkarni2005@gmail.com> URL: https://gitlist.dev/e/20250907081014.17466-1-jayatheerthkulkarni2005%40gmail.com In-Reply-To: <63045080-74d6-4835-9d9c-4d3558acdbfb@gmail.com> ``` To answer very shortly, "It is intended" Reason: I don't exactly know if I am pointing to the right code lines But if you dig into builtin/add.c you will find these lines /* * Check the "pathspec '%s' did not match any files" block * below before enabling new magic. */ parse_pathspec(&pathspec, 0, PATHSPEC_PREFER_FULL | PATHSPEC_SYMLINK_LEADING_PATH, prefix, argv); If you read the comment you will know this is already intented (the behaviour which you described) - Jayatheerth ``` ## Jeff King, 2025-09-07 23:34 Subject: Re: Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: <20250907233456.GA1281511@coredump.intra.peff.net> URL: https://gitlist.dev/e/20250907233456.GA1281511%40coredump.intra.peff.net In-Reply-To: <63045080-74d6-4835-9d9c-4d3558acdbfb@gmail.com> ``` On Sat, Sep 06, 2025 at 07:02:53PM -0700, Jon Forrest wrote: > Apparently the presence of even 1 invalid file invalidates > the whole 'git add' command, no matter how many valid files > are included. > > Is this deliberate? Yes. The C code here goes back to f25933987f (builtin-add: warn on unmatched pathspecs, 2006-05-17), which is in turn adapting 45e48120bb (Detect misspelled pathspec to git-add, 2006-02-15) from the shell version. Which is pulling the same feature from git-commit's bba319b5ce (commit: detect misspelled pathspec while making a partial commit., 2006-02-14). Which in turn from this thread: https://lore.kernel.org/git/7vfymlr7n8.fsf@assigned-by-dhcp.cox.net/ sounds like it came from cogito. I didn't follow the trail to the #git archives mentioned there. ;) Interestingly Pasky does mention that cogito behaved as you expected (quietly ignoring a single misspelling) and considered it a bug. I guess one could argue either way (though probably not at this point in time, as switching behaviors would cause confusion). But one challenge with "partial success" like this is that the exit code is binary. If we return "0" even though some items were ignored, callers may miss a failure. If we return "1" even though some items were added, callers may not realize they've mutated the state (and might need to rollback depending on what they were trying to accomplish). I think Git's philosophy is along the lines of: if we are not sure your command was well-formed, do nothing. You can always re-issue the command with a corrected set of arguments. -Peff ``` ## Jon Forrest, 2025-09-09 16:00 Subject: Re: Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: URL: https://gitlist.dev/e/b8df3605-7afe-4121-ae50-095dfd671df9%40gmail.com In-Reply-To: <20250907233456.GA1281511@coredump.intra.peff.net> ``` On 9/7/25 4:34 PM, Jeff King wrote: > I guess one could argue either way (though probably not at this point in > time, as switching behaviors would cause confusion). But one challenge > with "partial success" like this is that the exit code is binary. If we > return "0" even though some items were ignored, callers may miss a > failure. If we return "1" even though some items were added, callers may > not realize they've mutated the state (and might need to rollback > depending on what they were trying to accomplish). If this were a big deal, which it isn't, I'd suggest a command line flag that says what to do if there's an invalid file specified on the command line. One setting of the flag would result in the current behavior and the other setting would result in all the invalid file(s) being ignored and the valid file(s) being handled normally. Jon ``` ## Jon Forrest, 2025-09-09 18:33 Subject: Re: Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: <109prte$j8b$1@ciao.gmane.io> URL: https://gitlist.dev/e/109prte%24j8b%241%40ciao.gmane.io In-Reply-To: ``` On 9/9/25 9:00 AM, Jon Forrest wrote: > > > If this were a big deal, which it isn't, I'd suggest a command line > flag that says what to do if there's an invalid file specified on > the command line. One setting of the flag would result in the > current behavior and the other setting would result in all the > invalid file(s) being ignored and the valid file(s) being > handled normally. Nevermind. I should have checked the man page. The '--ignore-errors' option already does this. Sorry for the bother. Jon ``` ## Jeff King, 2025-09-09 18:40 Subject: Re: Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: <20250909184045.GA1912898@coredump.intra.peff.net> URL: https://gitlist.dev/e/20250909184045.GA1912898%40coredump.intra.peff.net In-Reply-To: ``` On Tue, Sep 09, 2025 at 09:00:34AM -0700, Jon Forrest wrote: > > I guess one could argue either way (though probably not at this point in > > time, as switching behaviors would cause confusion). But one challenge > > with "partial success" like this is that the exit code is binary. If we > > return "0" even though some items were ignored, callers may miss a > > failure. If we return "1" even though some items were added, callers may > > not realize they've mutated the state (and might need to rollback > > depending on what they were trying to accomplish). > > If this were a big deal, which it isn't, I'd suggest a command line > flag that says what to do if there's an invalid file specified on > the command line. One setting of the flag would result in the > current behavior and the other setting would result in all the > invalid file(s) being ignored and the valid file(s) being > handled normally. Interestingly there are a few --ignore-* options, including --ignore-missing, which I think does what you want. But it only works with --dry-run. I didn't dig into the rationale. -Peff ``` ## Jeff King, 2025-09-09 18:42 Subject: Re: Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: <20250909184231.GB1912898@coredump.intra.peff.net> URL: https://gitlist.dev/e/20250909184231.GB1912898%40coredump.intra.peff.net In-Reply-To: <109prte$j8b$1@ciao.gmane.io> ``` On Tue, Sep 09, 2025 at 11:33:18AM -0700, Jon Forrest wrote: > On 9/9/25 9:00 AM, Jon Forrest wrote: > > > > > > If this were a big deal, which it isn't, I'd suggest a command line > > flag that says what to do if there's an invalid file specified on > > the command line. One setting of the flag would result in the > > current behavior and the other setting would result in all the > > invalid file(s) being ignored and the valid file(s) being > > handled normally. > > Nevermind. I should have checked the man page. > The '--ignore-errors' option already does this. Oops, I think our mails just crossed. I don't think --ignore-errors does quite what you want, though: $ touch foo $ git add foo bar fatal: pathspec 'bar' did not match any files $ git add --ignore-errors foo bar fatal: pathspec 'bar' did not match any files $ git status --porcelain ?? foo -Peff ``` ## Junio C Hamano, 2025-09-09 20:55 Subject: Re: Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: URL: https://gitlist.dev/e/xmqqsegvtkgm.fsf%40gitster.g In-Reply-To: <20250909184231.GB1912898@coredump.intra.peff.net> ``` Jeff King writes: > Oops, I think our mails just crossed. I don't think --ignore-errors does > quite what you want, though: > > $ touch foo > $ git add foo bar > fatal: pathspec 'bar' did not match any files > $ git add --ignore-errors foo bar > fatal: pathspec 'bar' did not match any files > $ git status --porcelain > ?? foo The option is described like so: --[no-]ignore-errors just skip files which cannot be added because of errors I think "because of errors" is meant handle a sequence more like this: $ date >foo ; date >bar $ chmod a= foo $ git add --ignore-errors foo bar $ git diff --cached --name-only bar ``` ## Jeff King, 2025-09-09 21:01 Subject: Re: Is Git Add Supposed to Work Like This (git 2.50)? Message-ID: <20250909210138.GA1922525@coredump.intra.peff.net> URL: https://gitlist.dev/e/20250909210138.GA1922525%40coredump.intra.peff.net In-Reply-To: ``` On Tue, Sep 09, 2025 at 01:55:05PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Oops, I think our mails just crossed. I don't think --ignore-errors does > > quite what you want, though: > > > > $ touch foo > > $ git add foo bar > > fatal: pathspec 'bar' did not match any files > > $ git add --ignore-errors foo bar > > fatal: pathspec 'bar' did not match any files > > $ git status --porcelain > > ?? foo > > The option is described like so: > > --[no-]ignore-errors just skip files which cannot be added because of errors > > I think "because of errors" is meant handle a sequence more like this: > > $ date >foo ; date >bar > $ chmod a= foo > $ git add --ignore-errors foo bar > $ git diff --cached --name-only > bar > Yeah, I don't think --ignore-errors is misbehaving, and I read that doc. I just meant that it would not do the thing Jon is asking for. That is more like --ignore-missing. -Peff ```