{"thread":{"id":"2338","subject":"binary safe?","startedAt":"2005-11-03T22:02:20Z","lastAt":"2005-11-04T21:27:01Z","messageCount":9,"participants":["Randal L. Schwartz","Junio C Hamano","Linus Torvalds","Martin Langhoff","Nick Hengeveld","Chris Wedgwood","David Brown"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11090","messageId":"86br115r0z.fsf@blue.stonehenge.com","threadId":"2338","inReplyTo":null,"subject":"binary safe?","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2005-11-03T22:02:20Z","receivedAt":"2005-11-03T22:02:20Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":"\nI'm currently about to abandon CVS for my website management,\nreplacing it with git.\n\nWhat problems, if any, will I have using git to manage the binary\nfiles for my site, like the custom icons?  CVS is doing that just fine\nnow.\n\nI presume emailing diff-patches is out of the question, but if all I'm\ndoing is git-push and git-pull (using the shared central repository\nmodel), and if I'm stupid enough to have a merge error it's OK to just\nblow up on a binary file, will everything else work fine?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"11096","messageId":"7v7jbpbb3l.fsf@assigned-by-dhcp.cox.net","threadId":"2338","inReplyTo":"86br115r0z.fsf@blue.stonehenge.com","subject":"Re: binary safe?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-03T22:49:50Z","receivedAt":"2005-11-03T22:49:50Z","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 presume emailing diff-patches is out of the question, but if all I'm\n> doing is git-push and git-pull (using the shared central repository\n> model), and if I'm stupid enough to have a merge error it's OK to just\n> blow up on a binary file, will everything else work fine?\n\nIt should.  I trust git well enough to track some png files in\nmy day-job project.\n"},{"id":"11097","messageId":"Pine.LNX.4.64.0511031447020.27915@g5.osdl.org","threadId":"2338","inReplyTo":"86br115r0z.fsf@blue.stonehenge.com","subject":"Re: binary safe?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-03T22:50:21Z","receivedAt":"2005-11-03T22:50:21Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 3 Nov 2005, Randal L. Schwartz wrote:\n> \n> I'm currently about to abandon CVS for my website management,\n> replacing it with git.\n> \n> What problems, if any, will I have using git to manage the binary\n> files for my site, like the custom icons?  CVS is doing that just fine\n> now.\n\nGit doesn't have any textual representations anywhere.\n\nSo the _only_ problem should be \"git diff\" (and related patch-based tools \n- git-apply etc). They'll simply not work. For similar reasons, a \nthree-way merge will obviously fail.\n\n> I presume emailing diff-patches is out of the question, but if all I'm\n> doing is git-push and git-pull (using the shared central repository\n> model), and if I'm stupid enough to have a merge error it's OK to just\n> blow up on a binary file, will everything else work fine?\n\nYes. I don't think it's been heavily tested, but the very architecture of \ngit should mean that there just shouldn't be any issues with binary files \noutside of the obvious ones.\n\nThe only binary file the kernel ever uses is the logo.gif thing, so it's \nbeen \"tested\" in the sense that binary files exist, but there's never been \nany changes to that file, so..\n\n\t\tLinus\n"},{"id":"11099","messageId":"46a038f90511031500p3d6ed433s6efe3f5a5e60bcf8@mail.gmail.com","threadId":"2338","inReplyTo":"7v7jbpbb3l.fsf@assigned-by-dhcp.cox.net","subject":"Re: binary safe?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-03T23:00:54Z","receivedAt":"2005-11-03T23:00:54Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/4/05, Junio C Hamano <junkio@cox.net> wrote:\n> merlyn@stonehenge.com (Randal L. Schwartz) writes:\n>\n> > I presume emailing diff-patches is out of the question, but if all I'm\n> > doing is git-push and git-pull (using the shared central repository\n> > model), and if I'm stupid enough to have a merge error it's OK to just\n> > blow up on a binary file, will everything else work fine?\n>\n> It should.  I trust git well enough to track some png files in\n> my day-job project.\n\nYes it works, and cvsimport -k will do the right thing for you.\n\nWe are tracking projects with several binary files. The only issue as\nyou note is that trading patches with git-format-patch and git-am\ndoesn't quite deal with it. But you can still do it across different\ngit heads with git-read-tree -m as long as your binary file merges are\ntruly trivial.\n\ncheers,\n\n\nmartin\n"},{"id":"11100","messageId":"20051103230521.GA3001@reactrix.com","threadId":"2338","inReplyTo":"86br115r0z.fsf@blue.stonehenge.com","subject":"Re: binary safe?","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2005-11-03T23:05:21Z","receivedAt":"2005-11-03T23:05:21Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"On Thu, Nov 03, 2005 at 02:02:20PM -0800, Randal L. Schwartz wrote:\n\n> What problems, if any, will I have using git to manage the binary\n> files for my site, like the custom icons?  CVS is doing that just fine\n> now.\n\nWe're now using git in production to distribute content, of which well\nover 90% is binary files.  Works great.\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"11110","messageId":"20051104034910.GB5179@taniwha.stupidest.org","threadId":"2338","inReplyTo":"Pine.LNX.4.64.0511031447020.27915@g5.osdl.org","subject":"Re: binary safe?","fromName":"Chris Wedgwood","fromEmail":"cw@f00f.org","sentAt":"2005-11-04T03:49:10Z","receivedAt":"2005-11-04T03:49:10Z","isPatch":false,"sender":{"key":"cw@f00f.org","avatar":null},"body":"On Thu, Nov 03, 2005 at 02:50:21PM -0800, Linus Torvalds wrote:\n\n> So the _only_ problem should be \"git diff\" (and related patch-based\n> tools - git-apply etc). They'll simply not work. For similar\n> reasons, a three-way merge will obviously fail.\n\nI always thought it would be nice for binary files if SCMs could\nexport a summary of what ranges of bytes changes or even xdelta'ish\ndetails.\n\nGiven that people do stick large multi-MB binary blobs in SCMs and\nsometimes these update only a few bytes at a time it has some value.\n"},{"id":"11134","messageId":"20051104165419.GA12145@old.davidb.org","threadId":"2338","inReplyTo":"46a038f90511031500p3d6ed433s6efe3f5a5e60bcf8@mail.gmail.com","subject":"Re: binary safe?","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2005-11-04T16:54:19Z","receivedAt":"2005-11-04T16:54:19Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Fri, Nov 04, 2005 at 12:00:54PM +1300, Martin Langhoff wrote:\n\n> Yes it works, and cvsimport -k will do the right thing for you.\n\nUnless it has changed from 0.99.9b, 'cvsimport -k' will very much scramble\nsome binary files.  '-k' passes the '-kk' option which causes CVS to strip\nthe keywords down.  It needs to pass -ko through if you want it to be able\nto handle binary files.\n\nHowever, since CVS (RCS really) can remember the state of this flag, it\ndoes work to  'cvs admin -ko filename' beforehand, and then do the\ncvsimport without the '-k' option.\n\nDave\n"},{"id":"11150","messageId":"46a038f90511041322x1d9f7a50ndafe724c2e8d368b@mail.gmail.com","threadId":"2338","inReplyTo":"20051104165419.GA12145@old.davidb.org","subject":"Re: binary safe?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-11-04T21:22:29Z","receivedAt":"2005-11-04T21:22:29Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/5/05, David Brown <git@davidb.org> wrote:\n> On Fri, Nov 04, 2005 at 12:00:54PM +1300, Martin Langhoff wrote:\n>\n> > Yes it works, and cvsimport -k will do the right thing for you.\n>\n> Unless it has changed from 0.99.9b, 'cvsimport -k' will very much scramble\n> some binary files.  '-k' passes the '-kk' option which causes CVS to strip\n> the keywords down.  It needs to pass -ko through if you want it to be able\n> to handle binary files.\n\nThere is a misunderstanding here. We don't pass '-kk' to the cvs\nutility -- we pass it at the protocol level. Strangely enough, when\npassing ko we were getting broken files, and when passing kk we got\nall the files correctly. I explored and tested this quite a bit when I\nadded the flag, and explicitly tested it with files that _would_ get\nbroken with cvs update -kk.\n\nTo recap: my main test repository has a lot of binary files, files\nthat do get broken if I do a cvs checkout with -kk. git-cvsimport gets\nthem right with its -k parameter. Don't ask me why, though: the cvs\nprotocol is really messy, and I suspect that part of the -kk option is\nbeing 'implemented' on the client side.\n\n(That being said, if you have a case where git-cvsimport is doing the\nwrong thing, let me know!)\n\n> However, since CVS (RCS really) can remember the state of this flag, it\n> does work to  'cvs admin -ko filename' beforehand, and then do the\n> cvsimport without the '-k' option.\n\nYes, but a repo you don't control, where people are using keywords,\nmeans thatyou need to do -kk to kill the keywords or your imported\nfiles are going to have a horrid amount of noise in them.\n\ncheers,\n\n\nmartin\n"},{"id":"11151","messageId":"20051104212701.GA4310@old.davidb.org","threadId":"2338","inReplyTo":"46a038f90511041322x1d9f7a50ndafe724c2e8d368b@mail.gmail.com","subject":"Re: binary safe?","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2005-11-04T21:27:01Z","receivedAt":"2005-11-04T21:27:01Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Sat, Nov 05, 2005 at 10:22:29AM +1300, Martin Langhoff wrote:\n\n> (That being said, if you have a case where git-cvsimport is doing the\n> wrong thing, let me know!)\n> \n> > However, since CVS (RCS really) can remember the state of this flag, it\n> > does work to  'cvs admin -ko filename' beforehand, and then do the\n> > cvsimport without the '-k' option.\n> \n> Yes, but a repo you don't control, where people are using keywords,\n> means thatyou need to do -kk to kill the keywords or your imported\n> files are going to have a horrid amount of noise in them.\n\nYes, the unpleasantness of CVS.\n\nHowever, I was unable to do a proper git-cvsimport of the SourceForge 'vim'\narchive, with '-k'.  By not giving it '-k' and using cvs admin '-ko' on the\nappropriate files, I was able to get the correct results.\n\nMay be the interpretation of the option depends on the particular server\nbeing used?\n\nI can investigate later which particular file is causing the problem.\n\nDave\n"}]}