Re: possible bug in git apply?

Linus Torvalds [off-list ref] writes:

On Sun, 5 Aug 2007, David Kastrup wrote:

[...]

quoted

quoted

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.

But your proposed three passes won't work with a patch removing
"x/..."  and creating "x" in its place, since "x/" gets only removed
in pass 3, and "x" needs to created in pass 2 already.

If you had bothered reading my mail to the end: I explained exactly
that.  So your three pass scheme actually breaks the case for which
the two-pass scheme has been designed.

I propose you read my previous mail to its end: I explain a scheme
that will work in this case, but it would, as far as I understand
index processing, necessitate changing the index sort order, basically
having -depth order for deletion entries.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Sun, 5 Aug 2007, David Kastrup wrote:

But your proposed three passes won't work with a patch removing
"x/..."  and creating "x" in its place, since "x/" gets only removed
in pass 3, and "x" needs to created in pass 2 already.

Yes, I was wrong. The current two passes are the right thing to do, and we 
should just always remove empty directories (and my patch was fine: we can 
leave them alone if it's a pure "modify file in place", but that's really 
the only case).

		Linus