Yaroslav Halchenko <yoh@xxxxxxxxxxxxxx> 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.