I was thinking about this approach only for debugging purposes the OP mentioned. In usual environments I wouldn't dare doing it. If the build/debug system is strange enough and cannot be changed, this seems to be an (almost) reliable solution. On 1 Oct 2014 17:19, "Konstantin Khomoutov" <flatw...@users.sourceforge.net> wrote:
> 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.
