On Thu, Nov 25 2021, Philip Oakley wrote: > 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. Makes sense, but nothing being discussed here has to do with crossing repository boundaries so far. > 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. This behavior explicitly standardized in POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html: The special filename dot shall refer to the directory specified byits predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor directory. As a special case, in the root directory, dot-dot may refer to the root directory itself.c The same goes for "foo", "./foo", "./././././foo" etc. > 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. Yes, offhand I don't know where we canonically document our behavior of not crossing repo boundaries, or rather not going "up".
