Re: possible bug in git apply?

[Linus Torvalds <torvalds@linux-foundation.org>]

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