crash upon "commit removedfile/newfile removedfile"

crash upon "commit removedfile/newfile removedfile"

[Yaroslav Halchenko]

[-- Attachment #1.1: Type: text/plain, Size: 2881 bytes --]

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 O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

[-- Attachment #1.2: git-commit-removed.sh --]
[-- Type: application/x-sh, Size: 667 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: crash upon "commit removedfile/newfile removedfile"

[Junio C Hamano]

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.