On 12-12-11 04:27 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xxxxxxxxxxx> 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.
> 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.
> 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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html