On 24/11/2021 19:46, Junio C Hamano wrote:

Philip Oakley [off-list ref] writes:

quoted

On 24/11/2021 11:14, Ævar Arnfjörð Bjarmason wrote:

quoted

I'm not concerned that you didn't research this change well enough, I
just find it a bit iffy to introduce semantics in git around FS
operations that don't conform with that of POSIX & the underlying OS. My
*nix system happily accepts an "rm -rf" or an "rmdir" of the directory
I'm in, I'd expect git to do the same.

Isn't this the same, conceptually, as trying to remove the root
directory, but from a Git perspective?

i.e. Something along the lines of
https://superuser.com/questions/542978/is-it-possible-to-remove-the-root-directory
(their answer is 'no' without a special option, default since 2006)

If I read the arguments correctly, Elijah is saying that Git shouldn't
delete it's own root (cwd) directory, and that it is already implicit
within the current Git code.

I do not think it is about protecting "root"; the series wants

    cd t/ && git rm -r ../t

to leave an empty directory at 't/', because "git rm" was started in
that directory.

My point was about where the conceptual 'root' (for Git and it's rm
command) was deemed to be.

For instance, can/should we be able to elevate ourselves into a super
project for the deletion? I did notice that a regular `cd / && cd
../../` will happily recycle itself at `/`, rather than bugging out.

Whichever way is decided (cwd, GIT_WORK_TREE, or higher), ensuring that
the documentation is plain and clear , and not just the code, is
important for future readers, to help avoid future confusions.

Philip