On Sun, 5 Aug 2007, David Kastrup wrote: > > Which will let the user sit in an empty directory void of . and .., > and a parallel directory with the old name elsewhere. Unpretty... It actually depends on the OS. POSIX allows the case of "rmdir()" returning EBUSY if the directory is "in use", where "in use" may mean being somebodys current working directory. But yes, most UNIXes (Linux very much included) will just remove the directory, and yes, the user ends up sitting in a directory that is empty and not reachable from anywhere else. Easy enough to see: [torvalds@woody ~]$ mkdir test-me ; cd test-me ; rmdir $(pwd) [torvalds@woody test-me]$ ls -a [torvalds@woody test-me]$ pwd /home/torvalds/test-me [torvalds@woody test-me]$ /bin/pwd /bin/pwd: couldn't find directory entry in `..' with matching i-node (the first "pwd" is a shell built-in, and the shell caches is). Under Linux, you can also see funky things like this: [torvalds@woody test-me]$ ls -l /proc/self/cwd lrwxrwxrwx 1 torvalds torvalds 0 2007-08-05 11:09 /proc/self/cwd -> /home/torvalds/test-me (deleted) ie khe kernel actually shows you that you're in a deleted directory, that _used_ to be called "test-me". > > That said, if we really wanted to get it right, we should do this as > > a three-phase thing: (1) remove old files (2) create new files (3) > > for all removals and renames, try to remove source directories that > > might have become empty. > > > > That would fix it properly and for all cases. > > Stupid question from someone without good background: why do we need > two passes in the first place? For example, a patch that removes a directory structure "x/..." and then creates a file "x" in its place. In order for the patch ordering to not matter, you want to do the "remove old state" in an earlier phase. And patch order shouldn't matter, since you can have interesting things like mixing of renames and creates etc (ie maybe it's not "removing" that directory x, it's just moving all the contents somewhere else, and maybe the new file "x" is a move from somewhere else). Criss-crossing renames make it even more interesting. So git-apply actually does things in more than two phases: there's a whole another phase that is the "read the patch and create the in-memory result". The "two phases" above are actually just the two phases concerned with actually modifying the working tree, there's more phases elsewhere. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
