Philip Oakley [off-list ref] writes:
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.
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
On Thu, Nov 25 2021, Philip Oakley wrote:
On 24/11/2021 19:46, Junio C Hamano wrote:
quoted
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.
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".