Re: Git should preserve modification times at least on request

[Derek Fawcus]

On Wed, Feb 21, 2018 at 11:44:13PM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Feb 21 2018, Peter Backes jotted:
> > On Wed, Feb 21, 2018 at 10:33:05PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> 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).
> >
> > I think that this would be The Wrong Thing to do.

Agreed, but probably for a different reason.

> I'm merely pointing out that if you have the use-case Derek Fawcus
> describes you can get per-file mtimes via something similar to the the
> hook method Theodore Ts'o described today with a simple import tool with
> no changes to git or its object format required.

Actually, I was not proposing any change to the git objects.
I was simply suggesting a case where I'd have found a optional mechanism
for mtime restoration useful.

What would be useful is a better version of the hook based scheme which
Ted mentioned.  The import could be via a wrapper script, but checkouts
would have to be via a hook such that the original timestamps could then
be applied; and those stamps would have to be part of the tar-file commit.

The idea of automatically generating a bunch of commits in time order
would be the wrong thing here. That is because one file could well
contain changes from more than one logical commit (as guided by the
Changelog), and that one logical commit can be spread across a few
files with diffrent mode time, one has to manually tease those apart.

So here the purpose behind restoring the timestamps is as an aid in
guiding the examination of files to find the changes referenced in
the Changelog.

Git is quite useful for this sort of effort, as once a sensible commit
has been synthsized, rebase of the next tar-file commit then helps
reveal the next set of changes.

So what I'm thinking of is for stuff like this: 
https://github.com/DoctorWkt/unix-jun72
(and the other repros there), where one wishes to figure out and
regenerate a history of changes.  Since git is quite useful for
representing the end result, it is just that other scripting
may make it easier to use for such cases.

DF

Re: Git should preserve modification times at least on request

[Derek Fawcus]

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.

DF