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

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Dec 11, 2012, 22:07 UTC
Message-ID: <50C7AE84.2060400@xiplink.com>
In-Reply-To: <7vy5h47003.fsf@alter.siamese.dyndns.org>

On 12-12-11 04:27 PM, Junio C Hamano wrote:

Show 18 quoted lines

> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
>> 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.

Well, the makes I've used don't rebuild anything after a "touch *". I think it would surprise a lot of people if their make did rebuild files when their timestamps matched.

Show 7 quoted lines

> 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.

Yes, of course.  I would never expect otherwise.

Show 9 quoted lines

> 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.

Yes, I agree.

My point is that the initial checkout into an empty working directory should create all files with the same timestamp.

Or, to be a bit more precise, whenever git-checkout *creates* files in the work dir, *all* the created files should have the *same* timestamp (i.e. the current time measured at the start of the checkout's execution, not some bizarro other time specified by some arcane heuristic).

The more I think about it, the more I think it's sloppy for git-checkout to just let the filesystem assign the exact current time to created files. A checkout theoretically should be atomic -- you really shouldn't try to play with any of the files in your workdir while a checkout is underway. It's impractical to really make checkouts atomic, but I think the end result of a checkout should as much as possible look like the checkout happened all at one time.

Show 7 quoted lines

> 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.

I prefer to use the third-party code as-is, without hacking it, to have smooth upgrades in the future.

M.