Re: crash upon "commit removedfile/newfile removedfile"

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

Yaroslav Halchenko <yoh@onerussian.com> writes:

> 	+ rm p1
> 	+ mkdir p1
> 	+ touch p1/p2
> 	+ git add p1/p2
> 	+ git commit -m 2 p1/p2 p1
> 	error: 'p1' does not have a commit checked out
> 	fatal: updating files failed

Interesting.  In this toy example, all the user wants to do is to
remove p1 and add p1/p2, so an obvious workaround is to just say
"git commit" without any pathspec.  But in real life, there may
be cases where the user has already staged more than what the first
commit wants to have in the index, and want to limit it to a subset
by using a pathspec.

I _think_ the response from the command, seeing that the path 'p1'
that was previously a file got turned into a directory, is that it
is guessing that you are trying to replace 'p1' with a submodule,
but because 'p1' is not yet a repository, it cannot 'git add' the
commit from the 'p1' submodule to include it in the commit.  The
guess is wrong and it is a bug that it does not notice it---it knows
the user added 'p1/p2' to the index, so 'p1' clearly is a mere
subdirectory and not a submodule, so it could have known better than
saying "does not have a commit checked out".

By the way, program exit with non-zero status, with "fatal: message",
is a controlled error exit, not a crash.  Please reserve the word
"crash" to describe uncontrolled program death.

Thanks.