Re: Git should preserve modification times at least on request

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 21, 2018, 21:33 UTC
Message-ID: <87bmgif2pa.fsf@evledraar.gmail.com>
In-Reply-To: <20180221210339.GA43094@accordion.employees.org>

On Wed, Feb 21 2018, Derek Fawcus jotted:

Show 18 quoted lines

> On Mon, Feb 19, 2018 at 10:22:36PM +0100, Peter Backes wrote:
>>
>> It is pretty annoying that git cannot, even if I know what I am doing,
>> and explicitly want it to, preserve the modification time.
>
> The use case I've come across where it would be of value is for code
> archeology, either importing a bunch of tar files, or importing a
> repo from some other VCS.
>
> There preserving the mod times can be useful when one is subsequently
> figuring out what changed, and the scope of the 'commits' is too big
> (i.e. the granularity of the tar files themselves).
>
> e.g. initial commits are done on tar boundaries, but one may try to
> figure out individual changes from a ChangeLog file.  I've done this
> a couple of times, but to date it has required keeping the untarred
> trees around (or a timestamp list file from each tree), in addition
> to the git repro in to which one is then synthesizing smaller commits.

This sounds like a sensible job for a git import tool, i.e. import a target directory into git, and instead of 'git add'-ing the whole thing it would look at the mtimes, sort files by mtime, then add them in order and only commit those files that had the same mtime in the same commit (or within some boundary).

The advantage of doing this via such a tool is that you could tweak it to commit by any criteria you wanted, e.g. not mtime but ctime or even atime.

You'd get the same thing as you'd get if git's tree format would change to include mtimes (which isn't going to happen), but with a lot more flexibility.