git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: (bug?) Inconsistent workdir file timestamps after initial clone.

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 11, 2012, 21:27 UTC
Message-ID
<7vy5h47003.fsf@alter.siamese.dyndns.org>
In-Reply-To
<50C79D1F.1080709@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
Show 11 quoted lines
> Occasionally when doing a fresh clone of a repo, if the clock ticks at just
> the wrong time the checked-out files end up with different timestamps.
>
> The effect of this can be that, when "make" is run in the workdir it'll
> decide that some files are out of date and try to rebuild them.
>
> (In our particular case, our automated build-bot cloned a submodule of some
> third-party (i.e. not our) code, where a Makefile.in got an earlier timestamp
> than its dependent Makefile.am, so "configure && make" then tried to rebuild
> Makefile.in and the build failed because our build environment has the wrong
> version of automake.)

Even if you somehow arrange Makefile.in and Makefile.am to have the same timestamp, wouldn't it be up to your "make" to decide which one is newer? Certainly Makefile.in is not newer than Makefile.am, and it is free to try rebuilding it.

Also if you do this after any operation:
    $ rm Makefile.am
    $ git checkout Makefile.am

you will have Makefile.am that is newer than your Makefile.in and you will end up attempting to rebuild it.

The timestamp of a working tree file records the time at which it was created in your working tree. It does not have any relation to the commit or author timestamp of the commit you check it out of. If this command:

    $ git checkout @{1.dacade.ago} Makefile.am

gave your Makefile.am an ancient timestamp, it will break your build.

While not including files that can be rebuilt from the source may be the ideal solution, I've seen projects hide rules to rebuild such a "generated but needs special tools to build" and/or a "generated but normal developers do not have any business rebuilding" file (in your case, Makefile.in) in their Makefiles from the normal targets (like "make all") for this exact reason, when they choose to distribute such files by including in their commits.

Previous: Marc BranchaudNext: Marc Branchaud
Message 2 of 7 in “(bug?) Inconsistent workdir file timestamps after initial clone.”
  1. Marc BranchaudDec 11, 2012
  2. Junio C HamanoDec 11, 2012
  3. Marc BranchaudDec 11, 2012
  4. Junio C HamanoDec 11, 2012
  5. Marc BranchaudDec 12, 2012
  6. Torsten BögershausenDec 12, 2012
  7. Pyeron, Jason J CTR (US)Dec 12, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.