Is Git Add Supposed to Work Like This (git 2.50)?

(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

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

On Sat, Sep 06, 2025 at 07:02:53PM -0700, Jon Forrest wrote:

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

On 9/7/25 4:34 PM, Jeff King 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.

Jon

On 9/9/25 9:00 AM, Jon Forrest wrote:

Nevermind. I should have checked the man page. The '--ignore-errors' option already does this.

Sorry for the bother.

Jon

On Tue, Sep 09, 2025 at 11:33:18AM -0700, Jon Forrest wrote:

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

Jeff King <peff@peff.net> writes:

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

On Tue, Sep 09, 2025 at 01:55:05PM -0700, Junio C Hamano wrote:

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

On Tue, Sep 09, 2025 at 09:00:34AM -0700, Jon Forrest wrote:

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