Ok - I was wrong about the timestamps not getting updated. Thanks for that correction. However, what about the idea of associating the result of a build with the hash of the source files used by the build, and using git to compute the hash? On Wed, Apr 15, 2009 at 11:20 AM, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > On Wed, 15 Apr 2009, E R wrote: > >> I have an idea about integrating make with git, and I'm wondering if >> it is a reasonable thing to do. >> >> First of all, I am under the impression that git can quickly compute a >> hash of a directory and its contents. Is that correct? >> >> If so, suppose you using git to manage revision control of a project >> which has some components like 'lib1', 'lib2', etc. Typically you >> would perform something like: make clean; make all and 'make all' >> would perform 'make lib1' and 'make lib2'. When checking out a >> different revision of the project you would have to perform another >> 'make clean' before 'make all' since you aren't sure of what's changed >> and the timestamps of the derived files will be more recent than the >> timestamps of the source files. > > No, the timestamps of the changed source files will be newer than the > timestamps of the derived files. Git doesn't backdate files in working > directories, in order to avoid causing the problem you're trying to fix. > (And because getting the history is so quick and easy with git that > looking at dates on files in the filesystem is kind of pointless.) > > -Daniel > *This .sig left intentionally blank* > -- 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