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

From: Jeff King <peff@peff.net>
Date: Sep 7, 2025, 23:34 UTC
Message-ID: <20250907233456.GA1281511@coredump.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:

Show 5 quoted lines

> 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