Yes, I'm having the same problem, same apparent cause. Here's my workaround. Whenever the GIT_AUTHOR_DATE seems stuck, I clear it by hand:
C-u M-x setenv GIT_AUTHOR_DATE Cheers, Tom On Saturday, April 14, 2012 5:40:48 PM UTC-4, Nathan Yergler wrote: > > Good afternoon, > > I've been having a problem intermittently over the past month or so > that I finally took the time to track down yesterday. The symptom is > that I'd commit something to the git repository at work using magit, > and when I looked at the commit log, the date was in the past. This > was first pointed out to me by a co-worker who asked if I'd managed to > invent a time machine: fixing a bug we discovered yesterday a week ago > is a pretty neat party trick. Once I confirmed that I truly was not > Dr. Sam Beckett [1], I decided to track down the problem. > > Yesterday I noticed that a commit made through Magit had the incorrect > date, while a commit made from the command line (outside of Emacs) had > the correct date. When I started looking at magit.el, I found the > setting of GIT_AUTHOR_DATE in magit-log-edit-setup-author-env. My > hypothesis, which I was able to confirm, is that when you rewrite a > commit, GIT_AUTHOR_DATE is set. However, despite the fact > process-environment is set up as a local variable, the setting > persists -- running (get-env "GIT_AUTHOR_DATE") in *scratch* after > rewriting a commit returns the rewritten commit's date. Future commits > will all have the same date as the last rewritten commit. > > I started to go down the path of clearing the GIT_AUTHOR_* variables > from the process-environment when no author is present, but that would > preclude setting them outside of Emacs. I wonder if instead magit > should specify --author and/or --date to the command line if the > author information is present. > > Does that seem reasonable? Has anyone else run into this issue? > > Thanks, > > NRY > > [1] http://en.wikipedia.org/wiki/Quantum_Leap > >
