Re: How should I handle binary file with GIT

On Wed, 5 Apr 2006, Junio C Hamano wrote:

> If we wanted to use the patch+diff (i.e. "format-patch,
> send-email, and then am" workflow) to transfer new version of
> binary files to a recipient, which I think is useful in some
> projects, the sanest way to handle this is probably to add
> Nico's delta, going from preimage to postimage, encoded for
> safer transport, to our diff output.  For safety and sanity, we
> will not "apply" the patch unless the patched file exactly
> matches the preimage that is recorded in the diff, and as long
> as the recipient has the preimage, such a patch would be able to
> reproduce the postimage and hopefully be smaller than
> transferring the whole thing.

Exactly the point.

> We've been trying to keep our diff output reversible (e.g. we
> show what the filemode of the preimage is), so if we take the
> above route, it probably should record deltas for both going
> from preimage to postimage _and_ going the other way (unless
> xdelta can be applied in-reverse, which I do not think is the
> case).

You cannot reverse a delta.  However if you were able to apply a delta 
from preimage to postimage that means you must already have had preimage 
in your object store.  Therefore reverting such a patch would simply 
involve restoring preimage.

> Of course, to be _completely_ generic, you could include both
> compressed then uuencoded preimage and postimage, and let the
> recipient sort it out.

I think this is just too much and besides the point of a diff.  If the 
work flow is so convoluted such that the simple binary patch as a delta 
doesn't apply then it would probably be a better idea to simply transfer 
those binaries as email attachments.  In other words, if a binary patch 
transfer mechanism is added, it should cover the common case and leave 
the rest for a better process like git-fetch/pull.


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