{"thread":{"id":"3799","subject":"How should I handle binary file with GIT","startedAt":"2006-04-05T07:30:22Z","lastAt":"2006-04-05T20:20:34Z","messageCount":18,"participants":["moreau francis","Junio C Hamano","Nicolas Pitre","Jakub Narebski","Randal L. Schwartz","Shawn Pearce","Marco Roeland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18372","messageId":"20060405073022.13054.qmail@web25806.mail.ukl.yahoo.com","threadId":"3799","inReplyTo":null,"subject":"How should I handle binary file with GIT","fromName":"moreau francis","fromEmail":"francis_moreau2000@yahoo.fr","sentAt":"2006-04-05T07:30:22Z","receivedAt":"2006-04-05T07:30:22Z","isPatch":false,"sender":{"key":"francis_moreau2000@yahoo.fr","avatar":null},"body":"Hi,\n\nI'd like to use git to keep track of a documentation repository. This repo is\nmainly composed by text file and the documenation is generated by asciidoc.\nPeople who are using my repo and updating some docs which may include new\nimages can't send their whole work through patches.\n\nFor now they only send me the text updates through patch and attach new images\nwith the patch email. Then I do:\n\n $ git am < text_only_patch\n $ git reset --soft HEAD^\n $ git add \n $ git commit -a -C ORIG_HEAD\n\nNow my question: is it the best way to achieve this process ?\n\nthanks for you answers\n\nFrancis \n\n\n\t\n\n\t\n\t\t\n___________________________________________________________________________ \nNouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.\nTéléchargez sur http://fr.messenger.yahoo.com\n"},{"id":"18375","messageId":"7v3bgs4exz.fsf@assigned-by-dhcp.cox.net","threadId":"3799","inReplyTo":"20060405073022.13054.qmail@web25806.mail.ukl.yahoo.com","subject":"Re: How should I handle binary file with GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-05T08:14:16Z","receivedAt":"2006-04-05T08:14:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"moreau francis writes:\n\n> For now they only send me the text updates through patch and attach new images\n> with the patch email. Then I do:\n>\n> $ git am < text_only_patch\n> $ git reset --soft HEAD^\n> $ git add \n> $ git commit -a -C ORIG_HEAD\n>\n> Now my question: is it the best way to achieve this process ?\n\nIf I were doing that today, I would be doing almost exactly the\nabove sequence, or:\n\n\t$ git am patch\n $ git add \n $ git commit -a --amend\n\nIt _might_ make sense to adopt a well-defined binary patch\nformat (or if there is no prior art, introduce our own) and\nsupport that format with both git-diff-* brothers and git-apply,\nbut that would be a bit longer term project.\n\n\n \n"},{"id":"18377","messageId":"20060405122113.60376.qmail@web25801.mail.ukl.yahoo.com","threadId":"3799","inReplyTo":"7v3bgs4exz.fsf@assigned-by-dhcp.cox.net","subject":"Re: How should I handle binary file with GIT","fromName":"moreau francis","fromEmail":"francis_moreau2000@yahoo.fr","sentAt":"2006-04-05T12:21:13Z","receivedAt":"2006-04-05T12:21:13Z","isPatch":false,"sender":{"key":"francis_moreau2000@yahoo.fr","avatar":null},"body":"\n--- Junio C Hamano a écrit :\n\n> It _might_ make sense to adopt a well-defined binary patch\n> format (or if there is no prior art, introduce our own) and\n> support that format with both git-diff-* brothers and git-apply,\n> but that would be a bit longer term project.\n> \n\nwell maybe it's just stupid, but why not simply transforming binary files into\nascii files (maybe by using uuencode) before using git-diff-* brothers and\ngit-apply ?\n\nFrancis\n\n\n\t\n\n\t\n\t\t\n___________________________________________________________________________ \nNouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.\nTéléchargez sur http://fr.messenger.yahoo.com\n"},{"id":"18379","messageId":"Pine.LNX.4.64.0604050855080.2550@localhost.localdomain","threadId":"3799","inReplyTo":"7v3bgs4exz.fsf@assigned-by-dhcp.cox.net","subject":"Re: How should I handle binary file with GIT","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-04-05T13:06:48Z","receivedAt":"2006-04-05T13:06:48Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 5 Apr 2006, Junio C Hamano wrote:\n\n> It _might_ make sense to adopt a well-defined binary patch\n> format (or if there is no prior art, introduce our own) and\n> support that format with both git-diff-* brothers and git-apply,\n> but that would be a bit longer term project.\n\nWhat about simply using diff-delta and encoding its output with base64?\n\n\nNicolas\n"},{"id":"18380","messageId":"20060405131834.60888.qmail@web25804.mail.ukl.yahoo.com","threadId":"3799","inReplyTo":"7v3bgs4exz.fsf@assigned-by-dhcp.cox.net","subject":"Re: How should I handle binary file with GIT","fromName":"moreau francis","fromEmail":"francis_moreau2000@yahoo.fr","sentAt":"2006-04-05T13:18:34Z","receivedAt":"2006-04-05T13:18:34Z","isPatch":false,"sender":{"key":"francis_moreau2000@yahoo.fr","avatar":null},"body":"\n--- Junio C Hamano a écrit :\n\n> If I were doing that today, I would be doing almost exactly the\n> above sequence, or:\n> \n> \t$ git am patch\n> $ git add \n> $ git commit -a --amend\n> \n\nBTW, what does \"--amend\" option do ? It doesn't seem to be documented anywhere.\n\nFrancis\n\n\n\t\n\n\t\n\t\t\n___________________________________________________________________________ \nNouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.\nTéléchargez sur http://fr.messenger.yahoo.com\n"},{"id":"18382","messageId":"Pine.LNX.4.64.0604050906590.2550@localhost.localdomain","threadId":"3799","inReplyTo":"20060405122113.60376.qmail@web25801.mail.ukl.yahoo.com","subject":"Re: How should I handle binary file with GIT","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-04-05T13:25:42Z","receivedAt":"2006-04-05T13:25:42Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 5 Apr 2006, moreau francis wrote:\n\n> \n> --- Junio C Hamano a écrit :\n> \n> > It _might_ make sense to adopt a well-defined binary patch\n> > format (or if there is no prior art, introduce our own) and\n> > support that format with both git-diff-* brothers and git-apply,\n> > but that would be a bit longer term project.\n> > \n> \n> well maybe it's just stupid, but why not simply transforming binary files into\n> ascii files (maybe by using uuencode) before using git-diff-* brothers and\n> git-apply ?\n\nImagine if the only difference between two versions of the same file is \na single byte inserted at the very beginning. The uuencode would then \nbe totally different between the two files.\n\n\nNicolas\n"},{"id":"18383","messageId":"20060405133544.69578.qmail@web25802.mail.ukl.yahoo.com","threadId":"3799","inReplyTo":"Pine.LNX.4.64.0604050906590.2550@localhost.localdomain","subject":"Re: How should I handle binary file with GIT","fromName":"moreau francis","fromEmail":"francis_moreau2000@yahoo.fr","sentAt":"2006-04-05T13:35:44Z","receivedAt":"2006-04-05T13:35:44Z","isPatch":false,"sender":{"key":"francis_moreau2000@yahoo.fr","avatar":null},"body":"\n--- Nicolas Pitre a écrit :\n\n> On Wed, 5 Apr 2006, moreau francis wrote:\n> > \n> > well maybe it's just stupid, but why not simply transforming binary files\n> into\n> > ascii files (maybe by using uuencode) before using git-diff-* brothers and\n> > git-apply ?\n> \n> Imagine if the only difference between two versions of the same file is \n> a single byte inserted at the very beginning. The uuencode would then \n> be totally different between the two files.\n> \n\nok uuencode was just a bad example for encoding...\n\nFrancis\n\n\n\n\t\n\n\t\n\t\t\n___________________________________________________________________________ \nNouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.\nTéléchargez sur http://fr.messenger.yahoo.com\n"},{"id":"18388","messageId":"e10mn9$cjs$1@sea.gmane.org","threadId":"3799","inReplyTo":"7v3bgs4exz.fsf@assigned-by-dhcp.cox.net","subject":"Re: How should I handle binary file with GIT","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-05T15:11:43Z","receivedAt":"2006-04-05T15:11:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> It _might_ make sense to adopt a well-defined binary patch\n> format (or if there is no prior art, introduce our own) and\n> support that format with both git-diff-* brothers and git-apply,\n> but that would be a bit longer term project.\n\nbsdiff? http://www.daemonology.net/bsdiff/\nEDelta? http://www.diku.dk/~jacobg/edelta/\nXdelta? http://xdelta.blogspot.com/\n\nIIRC bsdiff is used by Firefox to distribute binary software updates.\nXdelta is generic (not optimized for binaries like bsdiff and edelta), but\nsupposedly offers worse compression (bigger diffs).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"18389","messageId":"Pine.LNX.4.64.0604051131010.2550@localhost.localdomain","threadId":"3799","inReplyTo":"e10mn9$cjs$1@sea.gmane.org","subject":"Re: How should I handle binary file with GIT","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-04-05T15:32:21Z","receivedAt":"2006-04-05T15:32:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 5 Apr 2006, Jakub Narebski wrote:\n\n> Junio C Hamano wrote:\n> \n> > It _might_ make sense to adopt a well-defined binary patch\n> > format (or if there is no prior art, introduce our own) and\n> > support that format with both git-diff-* brothers and git-apply,\n> > but that would be a bit longer term project.\n> \n> bsdiff? http://www.daemonology.net/bsdiff/\n> EDelta? http://www.diku.dk/~jacobg/edelta/\n> Xdelta? http://xdelta.blogspot.com/\n> \n> IIRC bsdiff is used by Firefox to distribute binary software updates.\n> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but\n> supposedly offers worse compression (bigger diffs).\n\nWe already have our own delta code for pack storage.\n\n\nNicolas\n"},{"id":"18390","messageId":"86wte4rq3d.fsf@blue.stonehenge.com","threadId":"3799","inReplyTo":"Pine.LNX.4.64.0604051131010.2550@localhost.localdomain","subject":"Re: How should I handle binary file with GIT","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-04-05T15:37:10Z","receivedAt":"2006-04-05T15:37:10Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Nicolas\" == Nicolas Pitre writes:\n\n>> IIRC bsdiff is used by Firefox to distribute binary software updates.\n>> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but\n>> supposedly offers worse compression (bigger diffs).\n\nNicolas> We already have our own delta code for pack storage.\n\nI think the issue is related to being able to cherry-pick and merge\nwhen binaries are involved. I've been worried about that myself.\nHow well are binaries supported these days for all the operations\nwe're taking for granted? When is a \"diff\" expected to be a real\n\"diff\" and not just \"binary files differ\"?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"18391","messageId":"20060405155528.GI14625@spearce.org","threadId":"3799","inReplyTo":"86wte4rq3d.fsf@blue.stonehenge.com","subject":"Re: How should I handle binary file with GIT","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-04-05T15:55:28Z","receivedAt":"2006-04-05T15:55:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Randal L. Schwartz\" wrote:\n> >>>>> \"Nicolas\" == Nicolas Pitre writes:\n> \n> >> IIRC bsdiff is used by Firefox to distribute binary software updates.\n> >> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but\n> >> supposedly offers worse compression (bigger diffs).\n> \n> Nicolas> We already have our own delta code for pack storage.\n> \n> I think the issue is related to being able to cherry-pick and merge\n> when binaries are involved. I've been worried about that myself.\n> How well are binaries supported these days for all the operations\n> we're taking for granted? When is a \"diff\" expected to be a real\n> \"diff\" and not just \"binary files differ\"?\n\nThe clearly safe approach is to include the full SHA1 ID of the\nold object the patch was created from and use the xdelta in the\npatch only as a means of transporting a compressed form of the new\nversion of the object. If git-diff starts to export say a base 64\nencoding of the xdelta then it should also include the full SHA1\nID for binary files, even if --full-index wasn't given.\n\ngit-apply should only apply an xdelta patch to the exact same\nold object. If the tree currently has a different object at that\npath then reject the patch entirely.\n\nIf a path has a different object then the patch was based on then\nwe can do one of two things to be ``nice'' to the human:\n\n - If the old blob exists in the repository (it just isn't the\n current version at that path) then generate a temporary merge\n file holding the old blob with the delta applied. The user can\n then finish the merge with whatever tool understands that binary\n file format, or do the merge by hand.\n\n - Supply a ``do it anyway'' flag to git-apply. If this flag is\n given on the command line then the binary file is patched even\n though the object versions differ. For some binary file formats\n this may actually be a valid thing to do. But it probably isn't\n for a very large percentage of known file formats.\n\nI could see some cases where it might be nice to be able to perform\nspecialized merge handling of binary files via hooks or filters.\n\nFor example *.tar.gz, *.zip, *.jar - these files are all just\ncompressed trees. They should be somewhat mergeable with the same\nsemantics as other trees in GIT. Of course one could just unpack\nthese into a directory and let GIT track the directory instead,\nbut this is rather inconvenient in a Java project. :-)\n\nIf I recall correctly OpenOffice document files are XML compressed\ninto ZIP archives. The XML *might* diff/patch cleanly as plain text.\nThe other resources in that archive are typically binary graphic\nfiles and the like, which of course wouldn't diff/patch nicely.\nBut being able to diff/patch the main content might be semi-useful.\n\n-- \nShawn.\n"},{"id":"18393","messageId":"Pine.LNX.4.64.0604051155090.2550@localhost.localdomain","threadId":"3799","inReplyTo":"86wte4rq3d.fsf@blue.stonehenge.com","subject":"Re: How should I handle binary file with GIT","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-04-05T16:21:49Z","receivedAt":"2006-04-05T16:21:49Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 5 Apr 2006, Randal L. Schwartz wrote:\n\n> >>>>> \"Nicolas\" == Nicolas Pitre writes:\n> \n> >> IIRC bsdiff is used by Firefox to distribute binary software updates.\n> >> Xdelta is generic (not optimized for binaries like bsdiff and edelta), but\n> >> supposedly offers worse compression (bigger diffs).\n> \n> Nicolas> We already have our own delta code for pack storage.\n> \n> I think the issue is related to being able to cherry-pick and merge\n> when binaries are involved. I've been worried about that myself.\n> How well are binaries supported these days for all the operations\n> we're taking for granted? When is a \"diff\" expected to be a real\n> \"diff\" and not just \"binary files differ\"?\n\nFirst of all, does cherry-picking binary patches is a sensible thing to \ndo?\n\nDo you expect, say, a Word document, a JPEG image, or an MP3 file to \nstill be valid and error free if two binary patches modifying a \ndifferent part of the same file (same revision) are successively \napplied? I seriously doubt it.\n\nAnd what do you do with conflicts? Using diff3 might be sensible for \ntext data, but for binaries you really need a tool that understands the \ntype of data your binary contains, which means one tool for each \npossible type of binary data which is outside the scope of GIT.\n\nFor example, if you patch a .wav file adding some data, then you end up \nwith the additional samples and a new length in the file header. If \nanother patch to that .wav is applied, then it is easy to find the \n\"surrounding context\" where the second patch is adding/removing some \nother samples, but then you really needs knowledge about the .wav format \nto handle the conflict that will occur on the .wav header modification.\n\nAnd so on for all possible binary types.\n\nSo IMHO a binary patch format is only useful for easy _transport_ along \nwith other text patches. And the binary patch must either apply \nperfectly against the same source file or it must not apply at all. \nThat's the only sensible accommodation we can do with a generic binary \npatch format.\n\nWhen the patch doesn't apply to your tree, then nothing prevents you \nfrom hooking a dedicated tool that will pick up the original file, the \nreconstructed remote version according to the binary patch you received \nand your own modified version so that tool can process them and do the \nnecessary changes with proper knowledge of the data format.\n\n\nNicolas\n"},{"id":"18394","messageId":"Pine.LNX.4.64.0604051223510.2550@localhost.localdomain","threadId":"3799","inReplyTo":"20060405155528.GI14625@spearce.org","subject":"Re: How should I handle binary file with GIT","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-04-05T16:25:29Z","receivedAt":"2006-04-05T16:25:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 5 Apr 2006, Shawn Pearce wrote:\n\n> The clearly safe approach is to include the full SHA1 ID of the\n> old object the patch was created from and use the xdelta in the\n> patch only as a means of transporting a compressed form of the new\n> version of the object. If git-diff starts to export say a base 64\n> encoding of the xdelta then it should also include the full SHA1\n> ID for binary files, even if --full-index wasn't given.\n> \n> git-apply should only apply an xdelta patch to the exact same\n> old object. If the tree currently has a different object at that\n> path then reject the patch entirely.\n\nAmen. Exactly what I just said.\n\n\nNicolas\n"},{"id":"18395","messageId":"7vslor27n4.fsf@assigned-by-dhcp.cox.net","threadId":"3799","inReplyTo":"86wte4rq3d.fsf@blue.stonehenge.com","subject":"Re: How should I handle binary file with GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-05T18:34:55Z","receivedAt":"2006-04-05T18:34:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> I think the issue is related to being able to cherry-pick and merge\n> when binaries are involved. I've been worried about that myself.\n> How well are binaries supported these days for all the operations\n> we're taking for granted? When is a \"diff\" expected to be a real\n> \"diff\" and not just \"binary files differ\"?\n\nFirst of all, binary files are handled by cherry-pick and merge\nwithout needing to involve \"diff\"+\"patch\" (which is not so\nuseful for binary files anyway). They use 3-way read-tree merge\nwhich compares the object names and leave the index unmerged if\nthere are conflicting changes, so you should be able to sort it\nout by running up to three \"git-cat-file blob $sha1\".\n\nWhat involves \"diff\"+\"patch\" are rebases and processing mailed-in\npatches as in the example by the original poster.\n\nIn our diff output, we record the blob object name of preimage\nand postimage, along with filemode, on the \"index\" line.\ngit-apply does not do anything with it by default, but if:\n\n - --binary flag is given,\n\n - the postimage blob is already available locally, and,\n\n - the file the patch is being applied to is the same as the\n recorded preimage,\n\nthen the file is _replaced_ with the postimage.\n\nThis is good enough for git-rebase (which uses format-patch\npiped to am) and is safe (we do not \"apply delta\" -- only\nreplace when the file \"being patched\" matches the recorded\npreimage). It does not do any good for transferring a postimage\nthat the person who applies the patch does not yet have.\n\nI think \"applying delta\" to a binary file is not very useful\nthing to do. Depending on the nature of the file being patched,\nit may produce a perfectly good result, but verifying if the\nresult makes sense by the end user and hand-fixing it if does\nnot, which can be done for text files, is near impossible for\nbinary files. \"replace with postimage only when you are\napplying to the same preimage\" rule would be the only practical,\nsane thing.\n\nIf we wanted to use the patch+diff (i.e. \"format-patch,\nsend-email, and then am\" workflow) to transfer new version of\nbinary files to a recipient, which I think is useful in some\nprojects, the sanest way to handle this is probably to add\nNico's delta, going from preimage to postimage, encoded for\nsafer transport, to our diff output. For safety and sanity, we\nwill not \"apply\" the patch unless the patched file exactly\nmatches the preimage that is recorded in the diff, and as long\nas the recipient has the preimage, such a patch would be able to\nreproduce the postimage and hopefully be smaller than\ntransferring the whole thing.\n\nWe've been trying to keep our diff output reversible (e.g. we\nshow what the filemode of the preimage is), so if we take the\nabove route, it probably should record deltas for both going\nfrom preimage to postimage _and_ going the other way (unless\nxdelta can be applied in-reverse, which I do not think is the\ncase).\n\nOf course, to be _completely_ generic, you could include both\ncompressed then uuencoded preimage and postimage, and let the\nrecipient sort it out. An advantage of that approach is that\nthe applicability of such a \"patch\" improves as the tools to\napply it improve, after the patch was originally generated. I\nhowever think that is only a theoretical advantage, not a very\npractical one.\n"},{"id":"18396","messageId":"86ek0bsvno.fsf@blue.stonehenge.com","threadId":"3799","inReplyTo":"7vslor27n4.fsf@assigned-by-dhcp.cox.net","subject":"Re: How should I handle binary file with GIT","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-04-05T18:51:39Z","receivedAt":"2006-04-05T18:51:39Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> If we wanted to use the patch+diff (i.e. \"format-patch,\nJunio> send-email, and then am\" workflow) to transfer new version of\nJunio> binary files to a recipient, which I think is useful in some\nJunio> projects, the sanest way to handle this is probably to add\nJunio> Nico's delta, going from preimage to postimage, encoded for\nJunio> safer transport, to our diff output.\n\nThis is what I was looking for, and thanks for confirming that at least within\na local respository, everything already works. Yeay.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"18398","messageId":"20060405192321.GA20854@fiberbit.xs4all.nl","threadId":"3799","inReplyTo":"20060405131834.60888.qmail@web25804.mail.ukl.yahoo.com","subject":"Re: How should I handle binary file with GIT","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-04-05T19:23:21Z","receivedAt":"2006-04-05T19:23:21Z","isPatch":false,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Wednesday April 5th 2006 moreau francis wrote:\n\n> BTW, what does \"--amend\" option do ? It doesn't seem to be documented anywhere.\n\nThis is the original commit text that introduced it:\n\ndiff-tree b4019f045646b1770a80394da876b8a7c6b8ca7b (from d320a5437f8304cf9ea3ee1898e49d643e005738)\nAuthor: Junio C Hamano \nDate: Thu Mar 2 21:04:05 2006 -0800\n\n git-commit --amend\n \n The new flag is used to amend the tip of the current branch. Prepare\n the tree object you would want to replace the latest commit as usual\n (this includes the usual -i/-o and explicit paths), and the commit log\n editor is seeded with the commit message from the tip of the current\n branch. The commit you create replaces the current tip -- if it was a\n merge, it will have the parents of the current tip as parents -- so the\n current top commit is discarded.\n \n It is a rough equivalent for:\n \n \t$ git reset --soft HEAD^\n \t$ ... do something else to come up with the right tree ...\n \t$ git commit -c ORIG_HEAD\n \n but can be used to amend a merge commit.\n \n Signed-off-by: Junio C Hamano \n\nSo in the original context you can add separate binaries to a commit\nof only text files that you just rescued from CVS or something and then\nchange the commit to include these binaries as well.\n\nI've sent a separate patch for the documentation for git-commit using\nJunio's clear explanation.\n-- \nMarco Roeland\n"},{"id":"18399","messageId":"Pine.LNX.4.64.0604051521480.2550@localhost.localdomain","threadId":"3799","inReplyTo":"7vslor27n4.fsf@assigned-by-dhcp.cox.net","subject":"Re: How should I handle binary file with GIT","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-04-05T19:31:05Z","receivedAt":"2006-04-05T19:31:05Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 5 Apr 2006, Junio C Hamano wrote:\n\n> If we wanted to use the patch+diff (i.e. \"format-patch,\n> send-email, and then am\" workflow) to transfer new version of\n> binary files to a recipient, which I think is useful in some\n> projects, the sanest way to handle this is probably to add\n> Nico's delta, going from preimage to postimage, encoded for\n> safer transport, to our diff output. For safety and sanity, we\n> will not \"apply\" the patch unless the patched file exactly\n> matches the preimage that is recorded in the diff, and as long\n> as the recipient has the preimage, such a patch would be able to\n> reproduce the postimage and hopefully be smaller than\n> transferring the whole thing.\n\nExactly the point.\n\n> We've been trying to keep our diff output reversible (e.g. we\n> show what the filemode of the preimage is), so if we take the\n> above route, it probably should record deltas for both going\n> from preimage to postimage _and_ going the other way (unless\n> xdelta can be applied in-reverse, which I do not think is the\n> case).\n\nYou cannot reverse a delta. However if you were able to apply a delta \nfrom preimage to postimage that means you must already have had preimage \nin your object store. Therefore reverting such a patch would simply \ninvolve restoring preimage.\n\n> Of course, to be _completely_ generic, you could include both\n> compressed then uuencoded preimage and postimage, and let the\n> recipient sort it out.\n\nI think this is just too much and besides the point of a diff. If the \nwork flow is so convoluted such that the simple binary patch as a delta \ndoesn't apply then it would probably be a better idea to simply transfer \nthose binaries as email attachments. In other words, if a binary patch \ntransfer mechanism is added, it should cover the common case and leave \nthe rest for a better process like git-fetch/pull.\n\n\nNicolas\n"},{"id":"18403","messageId":"7vy7yjzsdp.fsf@assigned-by-dhcp.cox.net","threadId":"3799","inReplyTo":"Pine.LNX.4.64.0604051521480.2550@localhost.localdomain","subject":"Re: How should I handle binary file with GIT","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-05T20:20:34Z","receivedAt":"2006-04-05T20:20:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 5 Apr 2006, Junio C Hamano wrote:\n>\n>> We've been trying to keep our diff output reversible (e.g. we\n>> show what the filemode of the preimage is), so if we take the\n>> above route, it probably should record deltas for both going\n>> from preimage to postimage _and_ going the other way (unless\n>> xdelta can be applied in-reverse, which I do not think is the\n>> case).\n>\n> You cannot reverse a delta. However if you were able to apply a delta \n> from preimage to postimage that means you must already have had preimage \n> in your object store. Therefore reverting such a patch would simply \n> involve restoring preimage.\n\nThe case I had in mind was where you shipped a tarball of the\ntip to somebody (or \"a shallow clone\"), and after seeing him\nhaving problems with that release, sending him a patch telling\nhim \"reverting this might help, could you please give it a try?\"\n\nOf course you could be nicer to him and generate the reverse\ndiff on your end in such a case instead.\n"}]}