On 09/06/2005 02:08 PM, Junio C Hamano wrote:
> Jeff Carr <jcarr@linuxmachines.com> writes:
> 
> 
>>... If I remember
>>correctly, there was some threads at the beginning of git about how
>>datestamps were not accurate so there was no point in setting them(?) Or
>>maybe I mis-understood.
> 
> 
> The point of those thread was that clocks on machines tend to be
> not so accurate and we should not take the timestamps *too*
> seriously.  We do record the time as accurately as the clock is
> maintained on the machine the commit is made, provided if the
> user does not override it with the GIT_COMMIT_DATE environment
> variable with a bogus value.
> 
> The way you use it to show changes made in a certain timeperiod
> is a good example that the information is useful.  The argument
> against relying on timestamp too much in that thread you are
> remembering was that it should not be used to see which commit
> came before which other commit when there is no parent-child
> ancestry between them.  It is still a useful hint, and we do use
> it as such, but as the recent merge-base fixes show it is just a
> hint and relying on it too much tends to screw things up.


OK, I understand better now. I was just setting the mtime via the last
time the file showed up in the git-whatchanged output. When I check out
a repository I do:

git-read-tree -m HEAD && git-checkout-cache -q -f -u -a
git-restore-mtime

This is probably also a really bad reimplementation of something. :)

All and all, really enjoying using git. It's better.
Jeff