On Tue, 30 Sep 2014 21:51:12 +0200
Gergely Polonkai <gerg...@polonkai.eu> wrote:

> 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…

I'm afraid this approach is wrong.

The main issue with it is that Git is only concerned about the file's
contents, not its modification date.  If you change the modification
time of a file in the work tree without touching its contents the only
effect this will have is forcing Git perform an extra check of the
file's contents against the hash value currently recorded for that file
in the index to verify the file's contents haven't really changed (and
the corresponding entry in the index will then be updated with the
actual file's mtime to avoid such check the next time).

The second problem is that *if* Git would store time values from the
filesystem's metadata along with blobs it would need to deal with
the fact a file might legitimately have different time values but the
same contents in different commits.

Hence the only approach that works is performing a recursive crawl of
the work tree, recording the time values from the filesystem metadata
for each file of interest and then somehow storing the properly
represented result in the repository -- linked with the commit that
crawl has been done for.

The format of the data produced is not really interesting (it should be
easy to parse by a tool which would update the metadata of the files in
the work tree, when requested) but chosing the way to store the
resulting file(s) in the object database is a more interesting topic.

One approach which seems to be rather common is gathering the metadata
before the commit is done (say, in a pre-commit hook), storing it in
the repository as an object and writing a special machine-parsable
header to the commit message referring to that object.  The problem
which arises is the need to keep live references to those objects for
them not being garbage-collected.  This can be done in a number of ways
(tags, a dedicated programmatically updated branch).

Another possibility is adding this metadata directly to commits
themselves.  Say, before a commit is recorded, gather the metadata
and write a file with it under a directory named ".metadata", then
add it to the index and commit.  The file should have a well-known
static name.  The upside of this approach is its simplicity, the
downside is that the metainformation is tightly coupled with the
contents (and will get in the way when merging etc).

One could also explore if `git notes` can be (ab)used to attach such
metainformation to commits.  Git notes are not pushed and fetched by
default, but this can be done.

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