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

Glen Choo [off-list ref] writes:

To me, a more compelling argument is that protecting cwd is important
in order to ensure correctness, and user experience is an incidental
benefit. AFAICT that is not the argument you are making, but perhaps
there is some correctness benefit as well?

I doubt there is.

It would be annoying if the command fails to remove a directory that
becomes empty after an operation only because your interactive shell
that spawned "git" was there, especially if your system allows
interactive shell to still sit in an unlinked directory.  After such
a rmdir, `/bin/pwd` or `cd ..` may not work, but then the only thing
you need to do to recover from this situation is to run `cd
/path/to/repository` and we can continue working, without having to
worry about a leftover directory.

That may be a more pleasant end-user experience than what is being
proposed, which forces you (1) to realize that you are in a
directory that was to be removed if you weren't sitting there, and
(2) to compute how many levels of otherwise empty directories were
left because of your presense, and (3) to go up sufficient number of
levels and manually run "rm -fr" the hierarchy, to recover.

So, I dunno.  It does make the end-user experience on such a system
that allows your cwd to go away equally unpleasant to the end-user
experience on a system that does not allow your cwd to go away, so
we might be gaining a bit in the consistency department, but as has
been already discussed, "git" level protection can only notice the
process immediately above us and we wouldn't be able to pay
attention to the fact some other unrelated process is using a
directory as its cwd, so even such a consistency argument does not
go all that far.