crash upon "commit removedfile/newfile removedfile"

Dear Git Gurus,

Originally ran into in DANDI project [#127] while using datalad [#6558] which uses git and git-annex.

"git commit" seems to not tolerate well whenever both removed path which became a directory and a file under that directory are provided to commit invocation along with the new file path under that directory. But it is ok whenever removed paths (staged or not) are provided to commit.

A reproducer of the former defect and latter behavior is attached, and execution of it on my laptop provides output pasted in full below, where you can see the

	+ 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

problematic use case and git commits just fine whenever removed paths provided in commit invocation:

	+ rm p2 p3
	+ git add p2
	+ git commit -m 'removed and even staged one of them' p2 p3
	[master 209490a] removed and even staged one of them
	 2 files changed, 0 insertions(+), 0 deletions(-)
	 delete mode 100644 p2
	 delete mode 100644 p3

I think such inconsistent behavior is a defect in git. Ideally the former "git commit -m 2 p1/p2 p1" shouldn't crash.

	git version 2.35.1.473.g83b2b277ed
	+ git init
	Initialized empty Git repository in /home/yoh/.tmp/git-h0HvnyH/.git/
	+ touch p1
	+ git add p1
	+ git commit -m 1
	[master (root-commit) c9e0bff] 1
	 1 file changed, 0 insertions(+), 0 deletions(-)
	 create mode 100644 p1
	+ 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
	+ echo 'that did not work when imho should have!'
	that did not work when imho should have!
	+ git commit -m 2 p1/p2
	[master 446b8dc] 2
	 1 file changed, 0 insertions(+), 0 deletions(-)
	 rename p1 => p1/p2 (100%)
	+ echo 'done -- committed just fine'
	done -- committed just fine
	+ touch p2 p3
	+ git add p2 p3
	+ git commit -m 3 p2 p3
	[master 19ffa50] 3
	 2 files changed, 0 insertions(+), 0 deletions(-)
	 create mode 100644 p2
	 create mode 100644 p3
	+ rm p2 p3
	+ git add p2
	+ git commit -m 'removed and even staged one of them' p2 p3
	[master 209490a] removed and even staged one of them
	 2 files changed, 0 insertions(+), 0 deletions(-)
	 delete mode 100644 p2
	 delete mode 100644 p3
	+ echo 'and it worked just fine'

[#127] https://github.com/dandi/dandisets/issues/127#issuecomment-1066934910 [#6558] DataLad bugreport https://github.com/datalad/datalad/issues/6558

Yaroslav Halchenko <yoh@onerussian.com> writes:

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.