On Tue, Nov 23, 2021 at 1:57 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Glen Choo <chooglen@xxxxxxxxxx> writes:
>
> > This doesn't sound like a typical definition of 'emptiness' to me, but I
> > can accept it if others also find it compelling. IOW if your definition
> > of 'emptiness' is compelling enough, then I'll be convinced that there
> > is no mixing of concerns and there would be no objection.
>
> FWIW, I do not find it compelling. I can grant that it might be
> convenient, but I do not think it is a good idea to explain the
> reason why the directory is protected is because it is "not empty".
Is the objection to my hand-wavy explanation? If so, point taken.
However, I'm curious if you're also objecting to my commit message
and/or the patch as well.
If your objection also includes my commit message, but not the patch,
would the following suit your taste better? :
"""
remove_path() was added in 4a92d1bfb784 (Add remove_path: a function to
remove as much as possible of a path, 2008-09-27) to, as it says, remove
as much of a path as possible. Why remove as much as possible? Well,
at the time we probably would have said something like:
* removing leading directories makes things feel tidy
* removing leading directories doesn't hurt anything so long as they
had no files in them.
However, the second reason (and perhaps also the first) do not hold when
that empty directory was the current working directory we inherited from
our parent process. Leaving the parent process in a deleted directory
can cause user confusion when subsequent processes fail: any git
command, for example, will immediately fail with
fatal: Unable to read current working directory: No such file or directory
Modify remove_path() so that the empty leading directories it also
deletes does not include the current working directory we inherited from
our parent process. Also do the same for remove_dir_recursively().
"""
