On Tue, Feb 20, 2018 at 2:05 PM, Peter Backes <rtc@xxxxxxxxxxxxxxxxxxx> wrote: > Hi Jeff, > > On Tue, Feb 20, 2018 at 04:16:34PM -0500, Jeff King wrote: >> I think there are some references buried somewhere in that wiki, but did >> you look at any of the third-party tools that store file metadata >> alongside the files in the repository? E.g.: >> >> https://etckeeper.branchable.com/ >> >> or >> >> https://github.com/przemoc/metastore >> >> I didn't see either of those mentioned in this thread (though I also do >> not have personal experience with them, either). >> >> Modification times are a subset of the total metadata you might care >> about, so they are solving a much more general problem. Which may also >> partially answer your question about why this isn't built into git. The >> general problem gets much bigger when you start wanting to carry things >> like modes (which git doesn't actually track; we really only care about >> the executable bit) or extended attributes (acls, etc). > > I know about those, but that's not what I am looking for. Those tools > serve entirely different purposes, ie., tracking file system changes. > I, however, am specifically interested in version control. > > In version control, the user checks out his own copy of the tree for > working. For this purpose, it is thus pointless to track ownership, > permissions (except for the x bit), xattrs, or any other metadata. In > fact, it can be considered the wrong thing to do. > > The modification time, however, is special. It clearly has its place in > version control. It tells us when the last modification was actually > done to the file. I am often working on some feature, and one part is > finished and is lying around, but I am still working on other parts in > other files. Then, maybe after some weeks, the other parts are > finished. Now, when committing, the information about modification time > is lost. Maybe some weeks later I want to figure out when I last > modified those files that were committed. But that information is now > gone, at least in the git repository. Sure, I could do lots of WIP > commits, but this would clutter up the history unneccessarly and I > would have lots of versions that might not even compile, let alone run. You could have git figure this out by the commit time of the last commit which modified a file. This gets a bit weird for cherry-picks or other things like rebase, but that should get what you want. If you only ever need this information sometimes, you can look it up by doing something like: git log -1 --pretty="%cd" -- <path to file> That should show the commit time of the latest commit which touches that file, which is "essentially" the modify time of the file in terms of the version control history. Obviously, this wouldn't work if you continually amend a change of multiple files, since git wouldn't track the files separately, and this only really shows you the time of the last commit. However, in "version control" sense, this *is* the last time a file was modified, since it doesn't really care about the stuff that happens outside of version control. I'm not really sure if this is enough for you, or if you really want to store the actual mtime for some reason? (I think you can likely solve your problem in some other way though). > > As far as I remember, bitkeeper had this distinction between checkins > and commits. You could check in a file at any time, and any number of > times, and then group all those checkins together with a commit. Git > seems to have avoided this principle, or have kept it only > rudimentarily via git add (but git add cannot add more than one version > of the same file). Perhaps for simplificiation of use, perhaps for > simplification of implementation, I don't know. > You can do lots of commits on a branch and then one merge commit to merge it into the main line. This is a common strategy used by many people. Thanks, Jake > I assume, if it were not for the build tool issues, git would have > tracked mtime from the very start. > Maybe. Personally, I would hate having my mtime not be "the time I checked the file out", since this is intuitive to me at this point. I'm sure if I lived in a different world I'd be used to that way also, though. The build issue *is* important though, because many build systems rely on the mtime to figure out what to rebuild, and a complete rebuild isn't a good idea for very large projects. Thanks, Jake > Best wishes > Peter > -- > Peter Backes, rtc@xxxxxxxxxxxxxxxxxxx
