{"thread":{"id":"10898","subject":"preserving mtime","startedAt":"2007-11-16T09:33:45Z","lastAt":"2007-11-19T14:38:55Z","messageCount":14,"participants":["Fabrizio Pollastri","Andreas Ericsson","Jakub Narebski","Junio C Hamano","Erik Warendorph","Wayne Davison","Mike Hommey","Martin Langhoff","Jan Hudec","Robin Rosenberg","David Brown","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60072","messageId":"473D63F9.4010201@inrim.it","threadId":"10898","inReplyTo":null,"subject":"preserving mtime","fromName":"Fabrizio Pollastri","fromEmail":"f.pollastri@inrim.it","sentAt":"2007-11-16T09:33:45Z","receivedAt":"2007-11-16T09:33:45Z","isPatch":false,"sender":{"key":"f.pollastri@inrim.it","avatar":null},"body":"Hi all,\nis it possible to tell git to preserve the file modification time in a \nchecked out copy? It is useful when managing web files, where mtime is \ntested by spiders for download decisions.\nThank you, for any help.\n\n--\nCheers,\nF. Pollastri\n"},{"id":"60073","messageId":"473D6DC6.8040804@op5.se","threadId":"10898","inReplyTo":"473D63F9.4010201@inrim.it","subject":"Re: preserving mtime","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-16T10:15:34Z","receivedAt":"2007-11-16T10:15:34Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Fabrizio Pollastri wrote:\n> Hi all,\n> is it possible to tell git to preserve the file modification time in a \n> checked out copy? It is useful when managing web files, where mtime is \n> tested by spiders for download decisions.\n\nNo. Doing so would seriously break build-systems. If you want you can\nhave a post-checkout hook that sets the mtime on all the files though.\nYou should be able to parse the time the commit being checked out was\nmade from HEAD.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"60075","messageId":"fhjqrp$v14$1@ger.gmane.org","threadId":"10898","inReplyTo":"473D63F9.4010201@inrim.it","subject":"Re: preserving mtime","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-16T10:19:32Z","receivedAt":"2007-11-16T10:19:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Fabrizio Pollastri wrote:\n\n> is it possible to tell git to preserve the file modification time in a \n> checked out copy? It is useful when managing web files, where mtime is \n> tested by spiders for download decisions.\n\nI don't quite understand. When git checks out copy, or switch branches,\nor resets it does update only files which changed.\n\nGit does not store mtime of files in tree object.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"60076","messageId":"7v1waqze1b.fsf@gitster.siamese.dyndns.org","threadId":"10898","inReplyTo":"473D63F9.4010201@inrim.it","subject":"Re: preserving mtime","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-16T10:21:36Z","receivedAt":"2007-11-16T10:21:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fabrizio Pollastri writes:\n\n> is it possible to tell git to preserve the file modification time in a\n> checked out copy? It is useful when managing web files, where mtime is\n> tested by spiders for download decisions.\n\n\"git checkout branchA\" after \"git checkout branchB\" would not\ntouch \"file\" if \"file\" are identical between two branches, so\nthe modification time is already preserved.\n\nIf the contents of \"file\" from the version you would want to\ncheck out is different from the version you previously checked\nout, and you still want to keep the old timestamp, then you are\ntrying to do something that a normal SCM user would actively not\nwant (e.g. doing so would screw up the build systems such as\n\"make\"). Such a specialized need usually is addressed by the\nbuild and install procedure of the application (in your case, a\nwebsite management). Maybe your current build procedure may\nblindly copy when installing:\n\n\tinstall: web.html\n \t$(install) web.html $(dest)/var/www/web.html\n\nbut you may want to ignore certain classes of changes and avoid\nre-installing to help crawlers. You would do:\n\n\tinstall = ./myinstall.sh\n\tinstall: web.html\n \t$(install) web.html $(dest)/var/www/web.html\n\nand then ./myinstall.sh might look like:\n\n\t#!/bin/sh\n\ttest -f \"$2\" &&\n compare-ignoring-minor-changes \"$1\" \"$2\" && exit 0\n\tinstall \"$1\" \"$2\"\n"},{"id":"60082","messageId":"20071116120929.GA28144@localhost.localdomain","threadId":"10898","inReplyTo":"473D63F9.4010201@inrim.it","subject":"Re: preserving mtime","fromName":"Erik Warendorph","fromEmail":"erik@warendorph.org","sentAt":"2007-11-16T12:09:30Z","receivedAt":"2007-11-16T12:09:30Z","isPatch":false,"sender":{"key":"erik@warendorph.org","avatar":null},"body":"* Fabrizio Pollastri [2007-11-16 10:33:45 +0100]:\n>\n> is it possible to tell git to preserve the file modification time in a \n> checked out copy? It is useful when managing web files, where mtime is \n> tested by spiders for download decisions.\n\nYou may find the script \"git-set-file-times\" in the GitWiki\nuseful:\n\n ExampleScripts - GitWiki\n Setting the timestamps of the files to the commit timestamp\n of the commit which last touched them\n \n\nYou should of course pay attention to advice about (and\nagainst) doing stuff like this, both in the description of that\nscript and in other postings on this list. But as you are\nusing Git to manage web files and you (probably) don't care\nabout build systems such as \"make\", you should be pretty safe.\n\nAbout the script: I think it originally was made by Eric Wong\n(= normalperson) who is also on this list. I have just made a\ntiny, tiny modification to it (adding \" or s/\\0$//\" to the\nelsif test).\n\nI've also thought about adding a --prefix option to the script.\nThis would enable it to be used together with git-archive,\nleaving the working directory alone and affecting the files in\nthe directory where the archive is extracted instead. In this\nway, you would distinguish between your working directory and\nyour \"live\" directory, and the command sequence\n\n git archive --prefix=foo/ HEAD | (cd /var/www/ && tar xf -)\n git-set-file-times --prefix=/var/www/foo/\n\nwould be part of the build system, publishing your working\ndirectory to your \"live\" directory (in this case\n/var/www/foo/).\n\n-- \nErik Warendorph \n"},{"id":"60157","messageId":"20071117182236.GD23659@blorf.net","threadId":"10898","inReplyTo":"473D6DC6.8040804@op5.se","subject":"Re: preserving mtime","fromName":"Wayne Davison","fromEmail":"wayne@opencoder.net","sentAt":"2007-11-17T18:22:36Z","receivedAt":"2007-11-17T18:22:36Z","isPatch":false,"sender":{"key":"wayne@opencoder.net","avatar":"https://gravatar.com/avatar/d55d81825271b1bfe65e57e4e04297d4119aa03c6a1c71d2ff2812b9b4be9f45?d=mp&s=160"},"body":"On Fri, Nov 16, 2007 at 11:15:34AM +0100, Andreas Ericsson wrote:\n>> is it possible to tell git to preserve the file modification time in\n>> a checked out copy?\n\n> Fabrizio Pollastri wrote:\n> No. Doing so would seriously break build-systems.\n\nI wish that the initial clone would set the modification time to the\ncommit time. It would make the intial checkout have a more accurate\nrepresentation of when a file was last changed instead of all files\nbeing set to the clone date. Then, files that are being updated would\nget their time set as they do now. I supposed I'll just use the handy\ngit-set-file-times script (mentioned in another reply) every time I do\na clone.\n\n..wayne..\n"},{"id":"60212","messageId":"20071118084511.GC16863@glandium.org","threadId":"10898","inReplyTo":"20071117182236.GD23659@blorf.net","subject":"Re: preserving mtime","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-18T08:45:11Z","receivedAt":"2007-11-18T08:45:11Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sat, Nov 17, 2007 at 10:22:36AM -0800, Wayne Davison wrote:\n> On Fri, Nov 16, 2007 at 11:15:34AM +0100, Andreas Ericsson wrote:\n> >> is it possible to tell git to preserve the file modification time in\n> >> a checked out copy?\n> \n> > Fabrizio Pollastri wrote:\n> > No. Doing so would seriously break build-systems.\n> \n> I wish that the initial clone would set the modification time to the\n> commit time. It would make the intial checkout have a more accurate\n> representation of when a file was last changed instead of all files\n> being set to the clone date. Then, files that are being updated would\n> get their time set as they do now. I supposed I'll just use the handy\n> git-set-file-times script (mentioned in another reply) every time I do\n> a clone.\n\nFor completeness, it would make sense to do so every time you git\ncheckout (like, when switching branches).\n\nMike\n"},{"id":"60215","messageId":"46a038f90711180134j411bb9c9uf2476f564f9abb6@mail.gmail.com","threadId":"10898","inReplyTo":"20071118084511.GC16863@glandium.org","subject":"Re: preserving mtime","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-11-18T09:34:55Z","receivedAt":"2007-11-18T09:34:55Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Nov 18, 2007 9:45 PM, Mike Hommey wrote:\n> On Sat, Nov 17, 2007 at 10:22:36AM -0800, Wayne Davison wrote:\n> > I wish that the initial clone would set the modification time to the\n> > commit time. It would make the intial checkout have a more accurate\n> > representation of when a file was last changed instead of all files\n...\n> For completeness, it would make sense to do so every time you git\n> checkout (like, when switching branches).\n\nI do hope anyone doing those things is _very_ aware that the mtime\nmetadata has a specific meaning -- when did this specific file in this\nfilesystem last change -- and is used by many tools in that sense. You\nare trying to use it for something else. Lots of things will break.\n\nLike incremental backups, for example.\n\nSo no no NO. Not recommended. Stuff will break in new and surprising\nways. It'd be trivial to write a quick script that shows the data you\nwant from git in Perl/Python/etc. But don't use mtime. It's used for\nother stuff. Actually used for other stuff. Don't replace that data\nwith time data you want to see, the actual users of mtime will break.\n\ncheers,\n\n\nm\n"},{"id":"60217","messageId":"20071118094038.GA11861@efreet.light.src","threadId":"10898","inReplyTo":"20071118084511.GC16863@glandium.org","subject":"Re: preserving mtime","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-18T09:40:38Z","receivedAt":"2007-11-18T09:40:38Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Nov 18, 2007 at 09:45:11 +0100, Mike Hommey wrote:\n> On Sat, Nov 17, 2007 at 10:22:36AM -0800, Wayne Davison wrote:\n> > On Fri, Nov 16, 2007 at 11:15:34AM +0100, Andreas Ericsson wrote:\n> > >> is it possible to tell git to preserve the file modification time in\n> > >> a checked out copy?\n> > \n> > > Fabrizio Pollastri wrote:\n> > > No. Doing so would seriously break build-systems.\n> > \n> > I wish that the initial clone would set the modification time to the\n> > commit time. It would make the intial checkout have a more accurate\n> > representation of when a file was last changed instead of all files\n> > being set to the clone date. Then, files that are being updated would\n> > get their time set as they do now. I supposed I'll just use the handy\n> > git-set-file-times script (mentioned in another reply) every time I do\n> > a clone.\n> \n> For completeness, it would make sense to do so every time you git\n> checkout (like, when switching branches).\n\n - That would still screw-up make hard. You know, checking out does NOT\n delete any untracked files.\n\n - There is no such thing as last modification time in git. Because there is\n no file history in git. (Besides, what would be last modification time of\n a file that was last modified in two parents, for example?)\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60227","messageId":"200711181142.07788.robin.rosenberg.lists@dewire.com","threadId":"10898","inReplyTo":"20071118094038.GA11861@efreet.light.src","subject":"Re: preserving mtime","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-11-18T10:42:07Z","receivedAt":"2007-11-18T10:42:07Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\nThere's an FAQ on this topic on the wiki as it pops up every now and then.\n\n-- robin\n"},{"id":"60246","messageId":"20071118184724.GA494@old.davidb.org","threadId":"10898","inReplyTo":"46a038f90711180134j411bb9c9uf2476f564f9abb6@mail.gmail.com","subject":"Re: preserving mtime","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-11-18T18:47:24Z","receivedAt":"2007-11-18T18:47:24Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Sun, Nov 18, 2007 at 10:34:55PM +1300, Martin Langhoff wrote:\n\n>I do hope anyone doing those things is _very_ aware that the mtime\n>metadata has a specific meaning -- when did this specific file in this\n>filesystem last change -- and is used by many tools in that sense. You\n>are trying to use it for something else. Lots of things will break.\n>\n>Like incremental backups, for example.\n\n'mtime' does _not_ have the specific meaning of 'when did this specific\nfile last change'. That is the 'ctime' field. 'mtime' is also updated\nwhen a file is modified, but can be changed by the user. Many utilities\nrestore mtime to older values, including tar.\n\nAny competent backup program would use 'ctime' for incremental backups,\nunless they don't mind missing a vast majority of files on many machines.\n\nThe main thing I've seen mess up backup software is if the mtime is set\ninto the future.\n\nHowever, it will make 'make' very confusing, since it uses the mtime to\ndetermine if files are out of date. If moving to an older version of a\nfile causes the file to become older, make won't recompile. This is\narguably a defect in make, but that is how it works.\n\nPreserving mtime definitely should not be a default.\n\nDavid\n"},{"id":"60253","messageId":"46a038f90711181236o1acd00d4id9c5aeffd3065b80@mail.gmail.com","threadId":"10898","inReplyTo":"20071118184724.GA494@old.davidb.org","subject":"Re: preserving mtime","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-11-18T20:36:52Z","receivedAt":"2007-11-18T20:36:52Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Nov 19, 2007 7:47 AM, David Brown wrote:\n> On Sun, Nov 18, 2007 at 10:34:55PM +1300, Martin Langhoff wrote:\n>\n> >I do hope anyone doing those things is _very_ aware that the mtime\n> >metadata has a specific meaning -- when did this specific file in this\n> >filesystem last change -- and is used by many tools in that sense. You\n> >are trying to use it for something else. Lots of things will break.\n> >\n> >Like incremental backups, for example.\n>\n> 'mtime' does _not_ have the specific meaning of 'when did this specific\n> file last change'. That is the 'ctime' field. 'mtime' is also updated\n> when a file is modified, but can be changed by the user. Many utilities\n> restore mtime to older values, including tar.\n\nHmmm. After a bit of googling I've found conflicting descriptions of\nthe mtime/ctime semantics (I thought - for 10 years now - that ctime\nwas \"creation time\", it is \"changed time\"). Some people think that\nanything that updates mtime also updates ctime, and others say the\nopposite.\n\nWikipedia says (at http://en.wikipedia.org/wiki/MAC_times and\nhttp://en.wikipedia.org/wiki/Stat_%28Unix%29 ) that mtime is about the\ncontent, and ctime about metadata (owner, permissions, moved inode,\netc). Changes in content \"touch\" mtime + ctime.\n\nWith that in mind, I think it makes sense for things like make and\namanda to read mtime as referring to a real change of that concrete\nfile. The abstract notion of the file having changed in the big DSCM\nin the sky is useful, but putting that data in mtime messes things up.\n\n> However, it will make 'make' very confusing, since it uses the mtime to\n> determine if files are out of date. If moving to an older version of a\n> file causes the file to become older, make won't recompile. This is\n> arguably a defect in make, but that is how it works.\n\nIt's not a bug in make. mtime has a definite meaning, and make is\nusing that meaning. Same with amanda.\n\ncheers,\n\n\nm\n"},{"id":"60254","messageId":"20071118214403.GA7182@old.davidb.org","threadId":"10898","inReplyTo":"46a038f90711181236o1acd00d4id9c5aeffd3065b80@mail.gmail.com","subject":"Re: preserving mtime","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-11-18T21:44:04Z","receivedAt":"2007-11-18T21:44:04Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Mon, Nov 19, 2007 at 09:36:52AM +1300, Martin Langhoff wrote:\n\n>Hmmm. After a bit of googling I've found conflicting descriptions of\n>the mtime/ctime semantics (I thought - for 10 years now - that ctime\n>was \"creation time\", it is \"changed time\"). Some people think that\n>anything that updates mtime also updates ctime, and others say the\n>opposite.\n\nOne of them is wrong. All modifications to the file change the ctime.\nSome modifications change the mtime. There is also a call to change the\nmtime (which will touch the ctime). It's been this way for a long time.\nI think most of the confusion comes from the 'c' in ctime.\n\nIt doesn't help that the Posix spec is so hard to read on this. Basically,\nyou have to look up every command that might modify a file to figure out\nwhich time changes it is supposed to modify.\n\n>Wikipedia says (at http://en.wikipedia.org/wiki/MAC_times and\n>http://en.wikipedia.org/wiki/Stat_%28Unix%29 ) that mtime is about the\n>content, and ctime about metadata (owner, permissions, moved inode,\n>etc). Changes in content \"touch\" mtime + ctime.\n>\n>With that in mind, I think it makes sense for things like make and\n>amanda to read mtime as referring to a real change of that concrete\n>file. The abstract notion of the file having changed in the big DSCM\n>in the sky is useful, but putting that data in mtime messes things up.\n\nBackup software should _never_ look at the mtime (other than to save it).\nBoth GNU tar and dump use the ctime field exclusively for incremental\npurposes.\n\nThink about this:\n\n wget .../linux-2.4.tar.gz\n tar -xzf linux-2.4.tar.gz\n\nI've just expanded lots of files on my machine. Tar is going to set the\nmtime to the date they were at when the tarball was made, which was\nprobably several years ago. It is crucial, though, that any backup\nsoftware I run still back these files up, since they are newly added.\n\nThere are backup programs that use mtime, but they are just broken, plain\nand simple.\n\n>> However, it will make 'make' very confusing, since it uses the mtime to\n>> determine if files are out of date. If moving to an older version of a\n>> file causes the file to become older, make won't recompile. This is\n>> arguably a defect in make, but that is how it works.\n>\n>It's not a bug in make. mtime has a definite meaning, and make is\n>using that meaning. Same with amanda.\n\nIt is very much a bug (well, a feature) in make. But the whole date\ncomparison model of make is completely wrong. It should rebuild a file if\nit has changed, not if it is newer. Most make replacements do something\nmore intelligent (often similar to the index cache git uses).\n\nI haven't used Amanda for a while, but it at least used to do the right\nthing (using ctime). They might have had to break things to support FAT,\nbut I would guess it still works on a real filesystem.\n\nDavid\n"},{"id":"60311","messageId":"Pine.LNX.4.64.0711191537030.16728@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"10898","inReplyTo":"20071117182236.GD23659@blorf.net","subject":"Re: preserving mtime","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-19T14:38:55Z","receivedAt":"2007-11-19T14:38:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Nov 2007, Wayne Davison wrote:\n\n> On Fri, Nov 16, 2007 at 11:15:34AM +0100, Andreas Ericsson wrote:\n> >> is it possible to tell git to preserve the file modification time in\n> >> a checked out copy?\n> \n> > Fabrizio Pollastri wrote:\n> > No. Doing so would seriously break build-systems.\n> \n> I wish that the initial clone would set the modification time to the\n> commit time.\n\nCould you stop this discussion, please? This subject comes up every once \nin a while, and in the meantime the archives contain more sane \nexplanations why this would be a bad behaviour of git than I could tell \noff of my head.\n\nSo no, this is not a sane behaviour.\n\nIf you _must_ inist on this behaviour, write your own hook, don't tell \nanybody about it, especially not when things break.\n\nHth,\nDscho\n"}]}