Ultimately, the reason that Git (and other Un*x-focused SCMs) behave this way is so that if you check out a new version and then run 'make', everything needed is rebuilt. If a file had new contents but its creation date is in the past, then files derived from it might not be rebuilt.
> From: Gergely Polonkai <gerg...@polonkai.eu> > > That said, it still can be done, although it is not natively supported, you > may do it with some custom tool. By finding the last commit a specific file > was modified in, you may apply the date of the commit to that file. > However, if you have a large repository, looking at this information for > each single file may take really long. Still, it looks like an interesting > project if your build environment really requires it… You know, a C program that walked up the tree of ancestor commits reading out the blob indexes in the file trees to assemble that data would run rather fast, because there's not a lot of data to be processed. There is a treacherous design question of defining exactly what date you want on each file. What *exactly* is the debugger looking for? (It probably isn't the date the file contents were first committed to the repository.) If the answer is "I need the file creation dates to match the dates recorded in XYZ." probably the easiest solution is to read the dates out of XYZ and apply them to the files. Dale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.