Re: Git should preserve modification times at least on request

From: Peter Backes <rtc@helen.plasma.xg8.de>
Date: Feb 20, 2018, 22:05 UTC
Message-ID: <20180220220525.GA25134@helen.PLASMA.Xg8.DE>
In-Reply-To: <20180220211634.GA15232@sigill.intra.peff.net>

Hi Jeff,

On Tue, Feb 20, 2018 at 04:16:34PM -0500, Jeff King wrote:

Show 19 quoted lines

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

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.

I assume, if it were not for the build tool issues, git would have tracked mtime from the very start.

Best wishes Peter

-- 
Peter Backes, rtc@helen.PLASMA.Xg8.DE