Re: [PATCH v2 7/9] git rm: do not abort due to an initialised submodule

[Junio C Hamano <gitster@pobox.com>]

Peter Collingbourne <peter@pcc.me.uk> writes:

> This patch causes the "git rm" command to consider "directory not
> empty" errors as nonfatal, which will be caused by a submodule being
> in an initialised state.  As this is a normal state for a submodule,
> ...
> Signed-off-by: Peter Collingbourne <peter@pcc.me.uk>
> ---
>  builtin/rm.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/rm.c b/builtin/rm.c
> index 6ac5114..02ee259 100644
> --- a/builtin/rm.c
> +++ b/builtin/rm.c
> @@ -250,7 +250,9 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
>  	 * abort the "git rm" (but once we've successfully removed
>  	 * any file at all, we'll go ahead and commit to it all:
>  	 * by then we've already committed ourselves and can't fail
> -	 * in the middle)
> +	 * in the middle).  However failure to remove a submodule
> +	 * directory due to the submodule being initialised is never
> +	 * a fatal condition.
>  	 */


Your messages both in the commit log and comment talk only about
submodules, ...

> @@ -261,7 +263,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
>  				removed = 1;
>  				continue;
>  			}
> -			if (!removed)
> +			if (!removed && errno != EEXIST && errno != ENOTEMPTY)
>  				die_errno("git rm: '%s'", path);
>  			else
>  				warning("git rm: '%s': %s", path, strerror(errno));

... but the code does not seem to limit itself to the case where a
submodule removal has failed.

How does this patch affect the failure case for regular files and
directories without any submodules?