On 24/11/2021 19:46, Junio C Hamano wrote: > Philip Oakley <philipoakley@iee.email> writes: > >> On 24/11/2021 11:14, Ævar Arnfjörð Bjarmason wrote: >>> 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
