Marc Branchaud <> 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 got an earlier timestamp
> than its dependent, so "configure && make" then tried to rebuild
> and the build failed because our build environment has the wrong
> version of automake.)

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

Also if you do this after any operation:

    $ rm
    $ git checkout

you will have that is newer than your 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}

gave your an ancient timestamp, it will break your

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, 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to