Subject: Re: [PATCH 8/8] dir: avoid removing the current working directory

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Thu, 25 Nov 2021 14:51:55 +0100

On Thu, Nov 25 2021, Philip Oakley wrote:

> On 24/11/2021 19:46, Junio C Hamano wrote:
>> Philip Oakley <[email-masked]> 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".