On Tue, 30 Sep 2014 08:17:10 -0700 (PDT)
Tom Green <tomgreen1...@gmail.com> wrote:

> I am working in Windows with GIT. 
> When I need to fix an older released version of our system I CHECKOUT
> that version. GIT restores the files in my working directory to the
> *contents* they had on that time. But it does not restore the *file
> dates*.
> This causes me problems because many of the tools we use look at file 
> dates, for example our debugger. I could make a copy on disk (or a
> zip file) of each branch before I switch away from it, instead of
> using GIT for this, but that really defeats the purpose of GIT.
> Is there a configuration option or other means to change that GIT
> behavior?


For the so-called blobs which represent the contents of tracked
files Git only stores these extra bits of information:
* Whether the file is a normal file or a symlink.
* If the file is normal, whether it's executable.

No other meta information is stored.

AFAIK, the official stance of the Git devs is that Git is not a
deployment solution or an archival system.  If you need to keep such
data in the repository, write a set of programs which would extract and
store the necessary metainformation and extract+restore/apply it when

This is understandable as once we decide to store metainformation for
files, it's hard to tell exactly where the line has to be drawn.
For instance, should we also somehow save Windows or POSIX ACLs?
Alternative NTFS streams?  POSIX extended attributes?  SELinux labels?
Filesystem-specific file attributes?  And the list goes on...

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