Linus Torvalds <torvalds@osdl.org> writes:

quoted text
> On Tue, 9 May 2006, Junio C Hamano wrote:
>> 
>> Junio C Hamano:
>>       binary patch.
>>       binary diff: further updates.
>
> Btw, am I just smoking stuff, or is this going to be fundamentally 
> problematic for "git-apply -R" if we ever want to support that?

It is problematic but not more than the current index + "Binary
files differ" output.  If you have both pre and postimage then
you do not need the binary data.

The forward application is done assuming you have the preimage
(but not necessarily postimage), and when you do not have
postimage the binary data is used.  When going reverse we should
assume you have the postimage (but not necessarily preimage),
but the pack-object format xdelta is not reversible so if you do
not have preimage that matches the index, with the current
output format you lose.

If we care enough, we could add a reverse delta from postimage
to preimage to the output, but I am not sure if it is worth it.

quoted text
> But at least in theory we might well want to do "-R" eventually.

Yes, but even without binary, -R has a funny implication when
copy-edit patch is involved.  What if a patch copy-edits to
create a new file B based on old A, and also modifies A
in-place, and somehow the postimages of A and B you already have
are not consistent with what that patch does?  Application with
-R would produce two versions of A and you would get a conflict.
I guess showing a combined diff would be a helpful way to
resolve that ;-).

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html