Re: possible bug in git apply?

From: David Kastrup <dak@gnu.org>
Date: Aug 5, 2007, 18:50 UTC
Message-ID: <853ayxiznp.fsf@lola.goethe.zz>
In-Reply-To: <alpine.LFD.0.999.0708051106020.5037@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sun, 5 Aug 2007, David Kastrup wrote:

[...]

Show 15 quoted lines

>> > 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