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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html