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

[Jeff King <peff@peff.net>]

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