As mentioned in "Git is ignoring files that aren't in gitignore"
Another reason for receiving this error message from Git is when executing the git submodule add
command while a previous git
command has crashed and left the lock file
(this can happen, for instance, when you use custom scripts which include git
commands and you haven't noted the crash).
In that case, an error message like "The following path is ignored by one of your .gitignore files
" is not very expressive.
With Git 2.26 (Q1 2020), said error message generation is improved for "git submodule add
".
See commit c816385 (08 Jan 2020) by Kyle Meyer (kyleam
).
(Merged by Junio C Hamano -- gitster
-- in commit 25794d6, 05 Feb 2020)
submodule add
: show 'add --dry-run
' stderr when aborting
Signed-off-by: Kyle Meyer
Unless --force
is specified, 'submodule add
' checks if the destination path is ignored by calling 'git add --dry-run --ignore-missing
', and, if that call fails, aborts with a custom "path is ignored
" message (a slight variant of what 'git add
' shows).
Aborting early rather than letting the downstream 'git add
' call fail is done so that the command exits before cloning into the destination path.
However, in rare cases where the dry-run call fails for a reason other than the path being ignored --- for example, due to a preexisting index.lock
file --- displaying the "ignored path
" error message hides the real source of the failure.
Instead of displaying the tailored "ignored path
" message, let's report the standard error from the dry run to give the caller more accurate information about failures that are not due to an ignored path.
For the ignored path case, this leads to the following change in the error message:
The following [-path is-]{+paths are+} ignored by one of your .gitignore files:
<destination path>
Use -f if you really want to add [-it.-]{+them.+}
The new phrasing is a bit awkward, because 'submodule add
' is only dealing with one destination path.
Alternatively, we could continue to use the tailored message when the exit code is 1 (the expected status for a failure due to an ignored path) and relay the standard error for all other non-zero exits.
That, however, risks hiding the message of unrelated failures that share an exit code of 1, so it doesn't seem worth doing just to avoid a clunkier, but still clear, error message.
So you will get a more explicit fatal:...
error message mentioning the index.lock
, instead of an "ignored path
"