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.

Reply via email to