Scroll to navigation

GIT-RESTORE-MTIME(1) General Commands Manual GIT-RESTORE-MTIME(1)

NAME

git-restore-mtime - Restore original modification time of files based on the date of the most recent commit that modified them

SYNOPSIS

[-h] [--quiet|--verbose]
[-C DIRECTORY] [--work-tree WORKDIR] [--git-dir GITDIR]
[--force] [--merge] [--first-parent] [--skip-missing]
[--no-directories] [--test] [--commit-time] [--oldest-time]
[--skip-older-than SECONDS] [--unique-times] [--version]
[PATHSPEC [PATHSPEC...]]

DESCRIPTION

Change the modification time (mtime) of files in the work tree based on the date of the most recent commit that modified the file, as an attempt to restore the original modification time. Useful when generating release tarballs.

Ignore untracked files and uncommitted deletions, additions and renames, and by default modifications too.

OPTIONS

Positional arguments:

Only modify paths matching PATHSPEC, relative to current directory. By default, update all but untracked files and submodules.

Optional arguments:

show help message and exit
Suppress informative messages and summary statistics.
Print additional information for each processed file. Specify twice to further increase verbosity.
Run as if restore-mtime was started in directory DIRECTORY. This affects how --work-tree, --git-dir and PATHSPEC arguments are handled. See git(1) for more information.
Path to the git repository, by default auto-discovered by searching the current directory and its parents for a .git/ subdirectory.
Path to the work tree root, by default the parent of GITDIR if it's automatically discovered, or the current directory if GITDIR is set.
Force updating files with uncommitted modifications. Untracked files and uncommitted deletions, renames and additions are always ignored.
Include merge commits. Leads to more recent times and more files per commit, thus with the same time, which may or may not be what you want. Including merge commits may lead to fewer commits being evaluated as files are found sooner, which can improve performance, sometimes substantially. But as merge commits are usually huge, processing them may also take longer. By default, merge commits are only used for files missing from regular commits.
Consider only the first parent, the "main branch", when evaluating merge commits. Only effective when merge commits are processed, either when --merge is used or when finding missing files after the first regular log search. See --skip-missing.
Do not try to find missing files. If merge commits were not evaluated with --merge and some files were not found in regular commits, by default restore-mtime searches for these files again in the merge commits. This option disables this retry, so files found only in merge commits will not have their timestamp updated.
Do not update directory timestamps. By default, use the time of its most recently created, renamed or deleted file. Note that just modifying a file will NOT update its directory time.
Test run: do not actually update any file timestamp.
Use commit time instead of author time.
Update times based on the oldest, instead of the most recent commit of a file. This reverses the order in which the git log is processed to emulate a file "creation" date. Note this will be inaccurate for files deleted and re-created at later dates.
Ignore files that are currently older than SECONDS. Useful in workflows that assume such files already have a correct timestamp, as it may improve performance by processing fewer files.
Ignore files older than the timestamp it would be updated to. Such files may be considered "original", likely in the author's repository.
Set the microseconds to a unique value per commit. Allows telling apart changes that would otherwise have identical timestamps, as git's time accuracy is in seconds.
show program's version number and exit

KNOWN ISSUES

Renames are poorly handled: it always changes the timestamps of files, even if no content was modified.
Directory timestamps are also limited to being modified only when files are added (created) or deleted in them.
In very large repositories, after running restore-mtime to modify the timestamp of several files, further git operations may emit the error:
  fatal: mmap failed: Cannot allocate memory.
This is harmless, and can be fixed by running git-status(1).

SEE ALSO

git(1), git-log(1), git-ls-files(1), git-status(1)
https://github.com/MestreLion/git-tools

AUTHOR

Rodrigo Silva (MestreLion) linux@rodrigosilva.com

2022-07-27