{"thread":{"id":"32315","subject":"(bug?) Inconsistent workdir file timestamps after initial clone.","startedAt":"2012-12-11T20:52:47Z","lastAt":"2012-12-12T17:26:40Z","messageCount":7,"participants":["Marc Branchaud","Junio C Hamano","Torsten Bögershausen","Pyeron, Jason J CTR (US)"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204688","messageId":"50C79D1F.1080709@xiplink.com","threadId":"32315","inReplyTo":null,"subject":"(bug?) Inconsistent workdir file timestamps after initial clone.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-11T20:52:47Z","receivedAt":"2012-12-11T20:52:47Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"Hi all,\n\nOccasionally when doing a fresh clone of a repo, if the clock ticks at just\nthe wrong time the checked-out files end up with different timestamps.\n\nThe effect of this can be that, when \"make\" is run in the workdir it'll\ndecide that some files are out of date and try to rebuild them.\n\n(In our particular case, our automated build-bot cloned a submodule of some\nthird-party (i.e. not our) code, where a Makefile.in got an earlier timestamp\nthan its dependent Makefile.am, so \"configure && make\" then tried to rebuild\nMakefile.in and the build failed because our build environment has the wrong\nversion of automake.)\n\nI'm completely unfamiliar with the clone-and-checkout parts of git's code, so\nmy first question really is if someone more familiar with the code could look\nat it (or at least point me to it) to verify whether or not such inconsistent\ntimestamps are possible.\n\nIf someone can please confirm that timestamps will always be consistent on\nthe initial checkout of a clone, then I'll have to hunt for a different cause\nof our build failure.\n\nHowever, if inconsistent timestamps are possible, I'd like to suggest that\nthis should be fixed.  (I'd learn the code and write a patch myself, but as\nsome of you may know I haven't had very much time for git hacking lately.)\n\nThanks!\n\n\t\tM.\n"},{"id":"204689","messageId":"7vy5h47003.fsf@alter.siamese.dyndns.org","threadId":"32315","inReplyTo":"50C79D1F.1080709@xiplink.com","subject":"Re: (bug?) Inconsistent workdir file timestamps after initial clone.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-11T21:27:24Z","receivedAt":"2012-12-11T21:27:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud <marcnarc@xiplink.com> writes:\n\n> Occasionally when doing a fresh clone of a repo, if the clock ticks at just\n> the wrong time the checked-out files end up with different timestamps.\n>\n> The effect of this can be that, when \"make\" is run in the workdir it'll\n> decide that some files are out of date and try to rebuild them.\n>\n> (In our particular case, our automated build-bot cloned a submodule of some\n> third-party (i.e. not our) code, where a Makefile.in got an earlier timestamp\n> than its dependent Makefile.am, so \"configure && make\" then tried to rebuild\n> Makefile.in and the build failed because our build environment has the wrong\n> version of automake.)\n\nEven if you somehow arrange Makefile.in and Makefile.am to have the\nsame timestamp, wouldn't it be up to your \"make\" to decide which one\nis newer?  Certainly Makefile.in is not newer than Makefile.am, and\nit is free to try rebuilding it.\n\nAlso if you do this after any operation:\n\n    $ rm Makefile.am\n    $ git checkout Makefile.am\n\nyou will have Makefile.am that is newer than your Makefile.in and\nyou will end up attempting to rebuild it.\n\nThe timestamp of a working tree file records the time at which it\nwas created in your working tree.  It does not have any relation to\nthe commit or author timestamp of the commit you check it out of.\nIf this command:\n\n    $ git checkout @{1.dacade.ago} Makefile.am\n\ngave your Makefile.am an ancient timestamp, it will break your\nbuild.\n\nWhile not including files that can be rebuilt from the source may be\nthe ideal solution, I've seen projects hide rules to rebuild such a\n\"generated but needs special tools to build\" and/or a \"generated but\nnormal developers do not have any business rebuilding\" file (in your\ncase, Makefile.in) in their Makefiles from the normal targets (like\n\"make all\") for this exact reason, when they choose to distribute\nsuch files by including in their commits.\n"},{"id":"204691","messageId":"50C7AE84.2060400@xiplink.com","threadId":"32315","inReplyTo":"7vy5h47003.fsf@alter.siamese.dyndns.org","subject":"Re: (bug?) Inconsistent workdir file timestamps after initial clone.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-11T22:07:00Z","receivedAt":"2012-12-11T22:07:00Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-12-11 04:27 PM, Junio C Hamano wrote:\n> Marc Branchaud <marcnarc@xiplink.com> writes:\n> \n>> Occasionally when doing a fresh clone of a repo, if the clock ticks at just\n>> the wrong time the checked-out files end up with different timestamps.\n>>\n>> The effect of this can be that, when \"make\" is run in the workdir it'll\n>> decide that some files are out of date and try to rebuild them.\n>>\n>> (In our particular case, our automated build-bot cloned a submodule of some\n>> third-party (i.e. not our) code, where a Makefile.in got an earlier timestamp\n>> than its dependent Makefile.am, so \"configure && make\" then tried to rebuild\n>> Makefile.in and the build failed because our build environment has the wrong\n>> version of automake.)\n> \n> Even if you somehow arrange Makefile.in and Makefile.am to have the\n> same timestamp, wouldn't it be up to your \"make\" to decide which one\n> is newer?  Certainly Makefile.in is not newer than Makefile.am, and\n> it is free to try rebuilding it.\n\nWell, the makes I've used don't rebuild anything after a \"touch *\".  I think\nit would surprise a lot of people if their make did rebuild files when their\ntimestamps matched.\n\n> Also if you do this after any operation:\n> \n>     $ rm Makefile.am\n>     $ git checkout Makefile.am\n> \n> you will have Makefile.am that is newer than your Makefile.in and\n> you will end up attempting to rebuild it.\n\nYes, of course.  I would never expect otherwise.\n\n> The timestamp of a working tree file records the time at which it\n> was created in your working tree.  It does not have any relation to\n> the commit or author timestamp of the commit you check it out of.\n> If this command:\n> \n>     $ git checkout @{1.dacade.ago} Makefile.am\n> \n> gave your Makefile.am an ancient timestamp, it will break your\n> build.\n\nYes, I agree.\n\nMy point is that the initial checkout into an empty working directory should\ncreate all files with the same timestamp.\n\nOr, to be a bit more precise, whenever git-checkout *creates* files in the\nwork dir, *all* the created files should have the *same* timestamp (i.e. the\ncurrent time measured at the start of the checkout's execution, not some\nbizarro other time specified by some arcane heuristic).\n\nThe more I think about it, the more I think it's sloppy for git-checkout to\njust let the filesystem assign the exact current time to created files.  A\ncheckout theoretically should be atomic -- you really shouldn't try to play\nwith any of the files in your workdir while a checkout is underway.  It's\nimpractical to really make checkouts atomic, but I think the end result of a\ncheckout should as much as possible look like the checkout happened all at\none time.\n\n> While not including files that can be rebuilt from the source may be\n> the ideal solution, I've seen projects hide rules to rebuild such a\n> \"generated but needs special tools to build\" and/or a \"generated but\n> normal developers do not have any business rebuilding\" file (in your\n> case, Makefile.in) in their Makefiles from the normal targets (like\n> \"make all\") for this exact reason, when they choose to distribute\n> such files by including in their commits.\n\nI prefer to use the third-party code as-is, without hacking it, to have\nsmooth upgrades in the future.\n\n\t\tM.\n"},{"id":"204698","messageId":"7vr4mw6x3p.fsf@alter.siamese.dyndns.org","threadId":"32315","inReplyTo":"50C7AE84.2060400@xiplink.com","subject":"Re: (bug?) Inconsistent workdir file timestamps after initial clone.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-11T22:30:02Z","receivedAt":"2012-12-11T22:30:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud <marcnarc@xiplink.com> writes:\n\n> My point is that the initial checkout into an empty working directory should\n> create all files with the same timestamp.\n>\n> Or, to be a bit more precise, whenever git-checkout *creates* files in the\n> work dir, *all* the created files should have the *same* timestamp (i.e. the\n> current time measured at the start of the checkout's execution, not some\n> bizarro other time specified by some arcane heuristic).\n\nMy knee-jerk reaction is that it is insane to do so, but what other\nSCM does such a thing? Even \"tar xf\" wouldn't do that, I think.\n\n>> While not including files that can be rebuilt from the source may be\n>> the ideal solution, I've seen projects hide rules to rebuild such a\n>> \"generated but needs special tools to build\" and/or a \"generated but\n>> normal developers do not have any business rebuilding\" file (in your\n>> case, Makefile.in) in their Makefiles from the normal targets (like\n>> \"make all\") for this exact reason, when they choose to distribute\n>> such files by including in their commits.\n>\n> I prefer to use the third-party code as-is, without hacking it, to have\n> smooth upgrades in the future.\n\nThen perhaps take the complaints to that third-party upstream, not\nhere?\n"},{"id":"204750","messageId":"50C8A766.30303@xiplink.com","threadId":"32315","inReplyTo":"7vr4mw6x3p.fsf@alter.siamese.dyndns.org","subject":"Re: (bug?) Inconsistent workdir file timestamps after initial clone.","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2012-12-12T15:48:54Z","receivedAt":"2012-12-12T15:48:54Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 12-12-11 05:30 PM, Junio C Hamano wrote:\n> Marc Branchaud <marcnarc@xiplink.com> writes:\n> \n>> My point is that the initial checkout into an empty working directory should\n>> create all files with the same timestamp.\n>>\n>> Or, to be a bit more precise, whenever git-checkout *creates* files in the\n>> work dir, *all* the created files should have the *same* timestamp (i.e. the\n>> current time measured at the start of the checkout's execution, not some\n>> bizarro other time specified by some arcane heuristic).\n> \n> My knee-jerk reaction is that it is insane to do so, but what other\n> SCM does such a thing?\n\nI'm lucky enough to just care about git these days.\n\n> Even \"tar xf\" wouldn't do that, I think.\n\n\"tar xf\" uses the timestamps that are stored in the tar file.  I see this as\nan argument against git's exact-current-time-per-file approach: even the tar\nguys understand that it's insane.\n\n>>> While not including files that can be rebuilt from the source may be\n>>> the ideal solution, I've seen projects hide rules to rebuild such a\n>>> \"generated but needs special tools to build\" and/or a \"generated but\n>>> normal developers do not have any business rebuilding\" file (in your\n>>> case, Makefile.in) in their Makefiles from the normal targets (like\n>>> \"make all\") for this exact reason, when they choose to distribute\n>>> such files by including in their commits.\n>>\n>> I prefer to use the third-party code as-is, without hacking it, to have\n>> smooth upgrades in the future.\n> \n> Then perhaps take the complaints to that third-party upstream, not\n> here?\n\nWell, I thought that while I wait for some dozen-or-so projects to accept\nchanges to their builds, it might be nice for git to solve this problem for\nme.  It is, after all, an effect of the way git operates.\n\n\t\tM.\n"},{"id":"204756","messageId":"50C8BC71.8030204@web.de","threadId":"32315","inReplyTo":"7vr4mw6x3p.fsf@alter.siamese.dyndns.org","subject":"Re: (bug?) Inconsistent workdir file timestamps after initial clone.","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2012-12-12T17:18:41Z","receivedAt":"2012-12-12T17:18:41Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\n \nOn 11.12.12 23:30, Junio C Hamano wrote:\n> Marc Branchaud <marcnarc@xiplink.com> writes:\n> \n>> My point is that the initial checkout into an empty working directory should\n>> create all files with the same timestamp.\n>>\n>> Or, to be a bit more precise, whenever git-checkout *creates* files in the\n>> work dir, *all* the created files should have the *same* timestamp (i.e. the\n>> current time measured at the start of the checkout's execution, not some\n>> bizarro other time specified by some arcane heuristic).\n> \n> My knee-jerk reaction is that it is insane to do so, but what other\n> SCM does such a thing? Even \"tar xf\" wouldn't do that, I think.\n> \n\n\nClearCase is doing such a thing.\n\nYou need to check out a file to make it writable:\n\"cleartool checkout main.c\"\n[hack hack]\nIf you after some hacking don't like your changes at all,\nyou run \n\"cleartool unco main.c\" (Undo checkout)\n(In git we just use \"git checkout\")\n\nWhile in ClearCase the timestamp of your file jumps back to where\nit was before the checkout, it gets the current timestamp in git.\n\nOne consequence is that ClearCase users may wish to use \"ClearMake\"\nrather then make.\n\nA better make (which records all timestamps somewhere) would be helpful.\n\n>>> While not including files that can be rebuilt from the source may be\n>>> the ideal solution, I've seen projects hide rules to rebuild such a\n>>> \"generated but needs special tools to build\" and/or a \"generated but\n>>> normal developers do not have any business rebuilding\" file (in your\n>>> case, Makefile.in) in their Makefiles from the normal targets (like\n>>> \"make all\") for this exact reason, when they choose to distribute\n>>> such files by including in their commits.\n>>\n>> I prefer to use the third-party code as-is, without hacking it, to have\n>> smooth upgrades in the future.\n> \n> Then perhaps take the complaints to that third-party upstream, not\n> here?\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"204758","messageId":"871B6C10EBEFE342A772D1159D13208539FF09F7@umechphj.easf.csd.disa.mil","threadId":"32315","inReplyTo":"50C8BC71.8030204@web.de","subject":"RE: (bug?) Inconsistent workdir file timestamps after initial clone.","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-12-12T17:26:40Z","receivedAt":"2012-12-12T17:26:40Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Torsten Bögershausen\n> Sent: Wednesday, December 12, 2012 12:19 PM\n> \n> \n> \n> On 11.12.12 23:30, Junio C Hamano wrote:\n> > Marc Branchaud <marcnarc@xiplink.com> writes:\n> >\n> >> My point is that the initial checkout into an empty working\n> directory should\n> >> create all files with the same timestamp.\n> >>\n> >> Or, to be a bit more precise, whenever git-checkout *creates* files\n> in the\n> >> work dir, *all* the created files should have the *same* timestamp\n> (i.e. the\n> >> current time measured at the start of the checkout's execution, not\n> some\n> >> bizarro other time specified by some arcane heuristic).\n> >\n> > My knee-jerk reaction is that it is insane to do so, but what other\n> > SCM does such a thing? Even \"tar xf\" wouldn't do that, I think.\n> >\n> \n> \n> ClearCase is doing such a thing.\n> \n> You need to check out a file to make it writable:\n> \"cleartool checkout main.c\"\n> [hack hack]\n> If you after some hacking don't like your changes at all,\n> you run\n> \"cleartool unco main.c\" (Undo checkout)\n> (In git we just use \"git checkout\")\n> \n> While in ClearCase the timestamp of your file jumps back to where\n> it was before the checkout, it gets the current timestamp in git.\n\nI do think that a user preference should decide if git uses metadata timestamps or current timestamp on file operations. I don’t think that the current time is proper as a default operation.\n\n> \n> One consequence is that ClearCase users may wish to use \"ClearMake\"\n> rather then make.\n> \n> A better make (which records all timestamps somewhere) would be\n> helpful.\n\nThat is why I always do \"make clean\" after a rollback. Do you really expect build managers to handle a bi-directional, with regards to time, SDLC? Build managers have worked hard to ensure incremental builds, it is silly to think that they should be re worked.\n\n\n> \n> >>> While not including files that can be rebuilt from the source may\n> be\n> >>> the ideal solution, I've seen projects hide rules to rebuild such a\n> >>> \"generated but needs special tools to build\" and/or a \"generated\n> but\n> >>> normal developers do not have any business rebuilding\" file (in\n> your\n> >>> case, Makefile.in) in their Makefiles from the normal targets (like\n> >>> \"make all\") for this exact reason, when they choose to distribute\n> >>> such files by including in their commits.\n> >>\n> >> I prefer to use the third-party code as-is, without hacking it, to\n> have\n> >> smooth upgrades in the future.\n> >\n> > Then perhaps take the complaints to that third-party upstream, not\n> > here?\n> > --\n> > To unsubscribe from this list: send the line \"unsubscribe git\" in\n> > the body of a message to majordomo@vger.kernel.org\n> > More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> >\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"}]}