* Is Git Add Supposed to Work Like This (git 2.50)?
@ 2025-09-07 2:02 Jon Forrest
2025-09-07 8:10 ` Re " K Jayatheerth
2025-09-07 23:34 ` Jeff King
0 siblings, 2 replies; 9+ messages in thread
From: Jon Forrest @ 2025-09-07 2:02 UTC (permalink / raw)
To: git
(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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re Is Git Add Supposed to Work Like This (git 2.50)?
2025-09-07 2:02 Is Git Add Supposed to Work Like This (git 2.50)? Jon Forrest
@ 2025-09-07 8:10 ` K Jayatheerth
2025-09-07 23:34 ` Jeff King
1 sibling, 0 replies; 9+ messages in thread
From: K Jayatheerth @ 2025-09-07 8:10 UTC (permalink / raw)
To: nobozo; +Cc: git
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is Git Add Supposed to Work Like This (git 2.50)?
2025-09-07 2:02 Is Git Add Supposed to Work Like This (git 2.50)? Jon Forrest
2025-09-07 8:10 ` Re " K Jayatheerth
@ 2025-09-07 23:34 ` Jeff King
2025-09-09 16:00 ` Jon Forrest
1 sibling, 1 reply; 9+ messages in thread
From: Jeff King @ 2025-09-07 23:34 UTC (permalink / raw)
To: Jon Forrest; +Cc: git
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is Git Add Supposed to Work Like This (git 2.50)?
2025-09-07 23:34 ` Jeff King
@ 2025-09-09 16:00 ` Jon Forrest
2025-09-09 18:33 ` Jon Forrest
2025-09-09 18:40 ` Jeff King
0 siblings, 2 replies; 9+ messages in thread
From: Jon Forrest @ 2025-09-09 16:00 UTC (permalink / raw)
To: Jeff King; +Cc: git
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is Git Add Supposed to Work Like This (git 2.50)?
2025-09-09 16:00 ` Jon Forrest
@ 2025-09-09 18:33 ` Jon Forrest
2025-09-09 18:42 ` Jeff King
2025-09-09 18:40 ` Jeff King
1 sibling, 1 reply; 9+ messages in thread
From: Jon Forrest @ 2025-09-09 18:33 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is Git Add Supposed to Work Like This (git 2.50)?
2025-09-09 16:00 ` Jon Forrest
2025-09-09 18:33 ` Jon Forrest
@ 2025-09-09 18:40 ` Jeff King
1 sibling, 0 replies; 9+ messages in thread
From: Jeff King @ 2025-09-09 18:40 UTC (permalink / raw)
To: Jon Forrest; +Cc: git
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is Git Add Supposed to Work Like This (git 2.50)?
2025-09-09 18:33 ` Jon Forrest
@ 2025-09-09 18:42 ` Jeff King
2025-09-09 20:55 ` Junio C Hamano
0 siblings, 1 reply; 9+ messages in thread
From: Jeff King @ 2025-09-09 18:42 UTC (permalink / raw)
To: Jon Forrest; +Cc: git
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is Git Add Supposed to Work Like This (git 2.50)?
2025-09-09 18:42 ` Jeff King
@ 2025-09-09 20:55 ` Junio C Hamano
2025-09-09 21:01 ` Jeff King
0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2025-09-09 20:55 UTC (permalink / raw)
To: Jeff King; +Cc: Jon Forrest, git
Jeff King <peff@peff•net> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is Git Add Supposed to Work Like This (git 2.50)?
2025-09-09 20:55 ` Junio C Hamano
@ 2025-09-09 21:01 ` Jeff King
0 siblings, 0 replies; 9+ messages in thread
From: Jeff King @ 2025-09-09 21:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Forrest, git
On Tue, Sep 09, 2025 at 01:55:05PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff•net> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-09-09 21:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-07 2:02 Is Git Add Supposed to Work Like This (git 2.50)? Jon Forrest
2025-09-07 8:10 ` Re " K Jayatheerth
2025-09-07 23:34 ` Jeff King
2025-09-09 16:00 ` Jon Forrest
2025-09-09 18:33 ` Jon Forrest
2025-09-09 18:42 ` Jeff King
2025-09-09 20:55 ` Junio C Hamano
2025-09-09 21:01 ` Jeff King
2025-09-09 18:40 ` Jeff King
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox