Glen Choo <chooglen@xxxxxxxxxx> 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.
