Keeping the file modification date with git

After heavily using git for code development, we plan to use it for administrative storage and I need to keep the modification date of the files.

Since I'm fond of git, I don't want to go back to some other tools I previously used but that keep the modification date... :-)

So I'm envisioning different solutions:

- it is already done. I have missed this. :-) But would be great. :-)

- giving up. Not an option :-)

- it is added to git core functions because it is quite useful for some
  people. Too time-consuming for me since I'm not a git developer... But
  someone else could do this...

- add this concept aside. For example, just as there are .gitignore or
  .gitattributes files, we could have a .gitdates that would store in a
  human-readable manner the modification time of the files in its
  directory.

  A nice side effect is that if we have conflicts on modification times
  during merge, we could just resolve conflict in the date file. :-) Of
  course, having merge tools aware of this could help the user to deal
  with this.

  By the way, we could consider modification time as a special attribute
  in .gitattributes to avoid yet another .git file? But I guess that the
  date information may be huge for a big directory, so it may be better
  to keep in a dedicated sorted file, to be processed efficiently
  without messing .gitattributes

  The implementation could be done with helper functions called from
  various hooks such as:

    - updating the .gitdates could be done in the pre-commit hook so
      that they are added to the commit when needed;

    - when a checkout is done, the date of some files may be update. I
      cannot see any hook for this...

  Well there are many things that should be triggered in the git
  plumbing or the user should have to launch explicitly some helper
  functions (for example to commit only a date change, since from the git
  point of view, nothing has changed and the commit is not done...).

  I have no idea about the execution time we would have on a big
  repository with many files, with a naive implementation to test the
  concept...

Any comments on the different approaches?

Thanks,