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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

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

I'm completely unfamiliar with the clone-and-checkout parts of git's code, so
my first question really is if someone more familiar with the code could look
at it (or at least point me to it) to verify whether or not such inconsistent
timestamps are possible.

If someone can please confirm that timestamps will always be consistent on
the initial checkout of a clone, then I'll have to hunt for a different cause
of our build failure.

However, if inconsistent timestamps are possible, I'd like to suggest that
this should be fixed.  (I'd learn the code and write a patch myself, but as
some of you may know I haven't had very much time for git hacking lately.)

Thanks!

		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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]