{"thread":{"id":"13098","subject":"Interaction between clean/smudge and git status","startedAt":"2008-04-13T23:25:14Z","lastAt":"2008-04-14T08:18:32Z","messageCount":6,"participants":["Sergio Callegari","Johannes Sixt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74273","messageId":"loom.20080413T231611-113@post.gmane.org","threadId":"13098","inReplyTo":null,"subject":"Interaction between clean/smudge and git status","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2008-04-13T23:25:14Z","receivedAt":"2008-04-13T23:25:14Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Hi,\n\nI have tried for the first time the .gitattributes filter option, setting a\nclean and a smudge filter for a certain type of files.\n\nWhat makes me wonder is that using filters, after a clean checkout git status\nsays that everything is changed.\n\nMy filter is a very short script that operates on zip files.\nThe clean command re-zips them so that the content is merely stored.\nThe smudge one re-zips them so that the content is deflated again.\n\nThis kind of filter helps very much the git repacking when zip files or\nopenoffice files are around.\n\nBut unfortunately, with it git shows everything as changed, which is not that\nnice.\n\nIs this the expected behaviour of the smudge filter?\nUnfortunately I have been able to find very little documentation on it (only a\nbit in the gitattributes man page), so maybe I am missing something.\n"},{"id":"74315","messageId":"4802FE3C.4090306@viscovery.net","threadId":"13098","inReplyTo":"loom.20080413T231611-113@post.gmane.org","subject":"Re: Interaction between clean/smudge and git status","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-04-14T06:48:28Z","receivedAt":"2008-04-14T06:48:28Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Sergio Callegari schrieb:\n> I have tried for the first time the .gitattributes filter option, setting a\n> clean and a smudge filter for a certain type of files.\n> \n> What makes me wonder is that using filters, after a clean checkout git status\n> says that everything is changed.\n...\n> Is this the expected behaviour of the smudge filter?\n\nI've observed this, too, and I don't think it is expected behavior. But it\nhasn't annoyed me enough to look at it in depth. Eventually I will, and I\nhope to find out what's wrong. ;)\n\n-- Hannes\n"},{"id":"74323","messageId":"7vej98apdo.fsf@gitster.siamese.dyndns.org","threadId":"13098","inReplyTo":"4802FE3C.4090306@viscovery.net","subject":"Re: Interaction between clean/smudge and git status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-14T07:04:35Z","receivedAt":"2008-04-14T07:04:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> Sergio Callegari schrieb:\n>> I have tried for the first time the .gitattributes filter option, setting a\n>> clean and a smudge filter for a certain type of files.\n>> \n>> What makes me wonder is that using filters, after a clean checkout git status\n>> says that everything is changed.\n\nWhat is to \"re-zip\"?  You have a .zip file that contains a single file in\nyour work tree, and the index and the tree objects record that single file\ndeflated?  When you \"check out\" from the index, you run smudge to create a\nnew .zip file with that single file?\n\n>> Is this the expected behaviour of the smudge filter?\n>\n> I've observed this, too, and I don't think it is expected behavior. But it\n> hasn't annoyed me enough to look at it in depth. Eventually I will, and I\n> hope to find out what's wrong. ;)\n\nAre you recreating the .zip file in the filter in such a way that a file\nwith the same contents results in byte-to-byte identical .zip file?\nOtherwise as far as git is concerned you have changed the file in the work\ntree.\n"},{"id":"74325","messageId":"48030607.60603@viscovery.net","threadId":"13098","inReplyTo":"7vej98apdo.fsf@gitster.siamese.dyndns.org","subject":"Re: Interaction between clean/smudge and git status","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-04-14T07:21:43Z","receivedAt":"2008-04-14T07:21:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> Johannes Sixt <j.sixt@viscovery.net> writes:\n>> I've observed this, too, and I don't think it is expected behavior. But it\n>> hasn't annoyed me enough to look at it in depth. Eventually I will, and I\n>> hope to find out what's wrong. ;)\n> \n> Are you recreating the .zip file in the filter in such a way that a file\n> with the same contents results in byte-to-byte identical .zip file?\n> Otherwise as far as git is concerned you have changed the file in the work\n> tree.\n\nIn my case, there is only a \"clean\" filter, and it rearranges the lines of\na particular type of text files in a canonical way. Hmm, I can't reproduce\nthe unwanted behavior in quick test now. I'll come back to this issue if\nit shows up again.\n\n-- Hannes\n"},{"id":"74328","messageId":"loom.20080414T072615-85@post.gmane.org","threadId":"13098","inReplyTo":"7vej98apdo.fsf@gitster.siamese.dyndns.org","subject":"Re: Interaction between clean/smudge and git status","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2008-04-14T07:38:58Z","receivedAt":"2008-04-14T07:38:58Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"Junio C Hamano <gitster <at> pobox.com> writes:\n\n\n> \n> What is to \"re-zip\"?  You have a .zip file that contains a single file in\n> your work tree, and the index and the tree objects record that single file\n> deflated?  When you \"check out\" from the index, you run smudge to create a\n> new .zip file with that single file?\n\nI have a zip file that contains a collection of files (or I have an openoffice\nfile that is just the same).  The program that creates the zip file uses default\ncompression.  In this way, things managed by git result in objects that cannot\nbe deltified one against the other very well by git repack.\n\nmy re-zip script takes a zip file on stdin, unpacks everything in a temporary\ndirectory, then recreates the archive with a different compression level and\nputs it out on stdout.  When the compression is 0, things are merely put in the\narchive. In this way the files managed git result in objects that do deltify\nwell one against the other and in much smaller packs.\n\n> Are you recreating the .zip file in the filter in such a way that a file\n> with the same contents results in byte-to-byte identical .zip file?\n> Otherwise as far as git is concerned you have changed the file in the work\n> tree.\n\nAnd here you are right!!!\nI thought that re-zip script was repeatable in behaviour, but it is not\n(probably because things like file dates change when files are unpacked in the\ntemporary dir and dates get stored).\n\nI absolutely overlooked that.\n\nThen to do what I want to do, I need to work at a lower level, I cannot just\nunzip and zip again.\n\nThanks\n"},{"id":"74338","messageId":"loom.20080414T074356-925@post.gmane.org","threadId":"13098","inReplyTo":"loom.20080414T072615-85@post.gmane.org","subject":"Re: Interaction between clean/smudge and git status","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2008-04-14T08:18:32Z","receivedAt":"2008-04-14T08:18:32Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Sergio Callegari <scallegari <at> arces.unibo.it> writes:\n\n> \n> Junio C Hamano <gitster <at> pobox.com> writes:\n> \n> \n> > Are you recreating the .zip file in the filter in such a way that a file\n> > with the same contents results in byte-to-byte identical .zip file?\n> > Otherwise as far as git is concerned you have changed the file in the work\n> > tree.\n> \n> And here you are right!!!\n> I thought that re-zip script was repeatable in behaviour, but it is not\n> (probably because things like file dates change when files are unpacked in the\n> temporary dir and dates get stored).\n> \n> I absolutely overlooked that.\n> \n\nOK, here is a testcase too...\n\nmkdir TEST\ngit init\n# create zip file x.zip\ngit add x.zip\ngit commit\n\nIn this git commit the clean filter runs.\n\nrm x.zip\n\ngit checkout x.zip\n\nor \n\ngit reset --hard\n\nIn this checkout the smudge filter runs\n\ngit status\n\nIt says that x.zip is changed\n\nAnd yes, in some sense it is changed, because it is a different file than the\none I had before the check in. But no, in some other sense it is not changed,\nbecause it is the file that I have just checked out (it has not been touched\nafter the checkout).\n\nNot that if I had only the clean filter and not the smudge one, then the same\nwould have happened. \n\n\nSo I think that I see your point: if the clean/smudge filters always provide the\nsame output independently from when they are run, then I get the message about\nthe changed file at most once, when I check in for the first time the \"cleaned\"\nfile.  \n\nAnd this behaviour makes sense: to say that nothing has changed, git wants\nthings to be identical.  However it is a bit counterintuitive, because one would\nthink that something that has just been freshly checked out should not be\nconsidered as changed anyway.\n\nI wonder if this comes from the fact that when git status is run, git compares\nthe workdir file with the index and the index contains information on the file\nas it was before the last checkin.  When filters exist, wouldn't it make sense\nto have the index hold information on the files as they are after the checkout?\n\nSergio \n"}]}