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
