Re: What's in git.git

From: Junio C Hamano <junkio@cox.net>
Date: May 10, 2006, 04:41 UTC
Message-ID: <7vd5emze3h.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0605092117240.3718@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 8 quoted lines

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

> 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 ;-).