GIT-RESTORE-MTIME(1)

πŸ“¦
version 2025.08 Β· 2 versions
  • 2025.08 Β· debian bookworm, debian trixie, epel 10, epel 9, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 2020.09 Β· ubuntu jammy
, in debian bookworm, debian trixie, epel 10, epel 9, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– GIT-RESTORE-MTIME(1) πŸ’–

okay bestie so this is from the General Commands Manual and it's literally one of the most useful little gremlins in the git-tools family. let's get into it πŸ¦‹


✨ NAME ✨

git-restore-mtime β€” restore the original modification time of files based on the date of the most recent commit that modified them 🌸


✨ SYNOPSIS ✨

git-restore-mtime [-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 ✨

so what this does: it changes the modification time (mtime) of files in the work tree, based on the date of the most recent commit that touched each file. it's basically an attempt to restore the original mtime, which is so useful when you're generating release tarballs πŸ“¦βœ¨

it ignores untracked files, and uncommitted deletions, additions and renames. and by default? modifications too πŸ™ˆ


✨ OPTIONS ✨

πŸŽ€ Positional arguments

  • PATHSPEC β€” only modify paths matching PATHSPEC, relative to the current directory. by default it updates everything except untracked files and submodules 🫢

πŸŽ€ Optional arguments

  • -h, --help β€” show the help message and exit, iconic behaviour honestly
  • --quiet,-q β€” suppress informative messages and summary statistics 🀫
  • --verbose,-v β€” print additional information for each processed file. specify it twice to crank the verbosity up even further πŸ”₯
  • -C DIRECTORY, --cwd DIRECTORY β€” run as if restore-mtime was started in directory DIRECTORY. this affects how the --work-tree, --git-dir and PATHSPEC arguments are handled. peep git(1) for more info πŸ’…
  • --git-dir GITDIR β€” path to the git repository. by default it's auto-discovered by searching the current directory and its parents for a .git/ subdirectory πŸ”
  • --work-tree WORKDIR β€” path to the work tree root. by default it's the parent of GITDIR if that was automatically discovered, or the current directory if GITDIR is set πŸ—‚οΈ
  • --force, -f β€” force updating files that have uncommitted modifications. but bestie, note this: untracked files and uncommitted deletions, renames and additions are always ignored, no exceptions 😀
  • --merge, -m β€” include merge commits. this leads to more recent times and more files per commit, which means they all get the same time β€” which may or may not be what you want, iykyk πŸ€·β€β™€οΈ including merge commits may also lead to fewer commits being evaluated since files get 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 that are missing from regular commits.
  • --first-parent β€” consider only the first parent, aka the "main branch", when evaluating merge commits. only effective when merge commits are actually processed β€” either when --merge is used, or when finding missing files after the first regular log search. see --skip-missing πŸ‘‘
  • --skip-missing, -s β€” do not try to find missing files. if merge commits weren't evaluated with --merge and some files weren't found in regular commits, by default restore-mtime searches for those files again in the merge commits. this option disables that retry, so files found only in merge commits will not have their timestamp updated πŸ’€
  • --no-directories, -D β€” do not update directory timestamps. by default it uses the time of its most recently created, renamed or deleted file. note that just modifying a file will NOT update its directory time πŸ™…β€β™€οΈ
  • --test, -t β€” test run: don't actually update any file timestamp. a lil dress rehearsal 🎭
  • --commit-time, -c β€” use commit time instead of author time ⏰
  • --oldest-time, -o β€” update times based on the oldest commit instead of the most recent one 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 πŸ•°οΈ
  • --skip-older-than SECONDS β€” ignore files that are currently older than SECONDS. useful in workflows that assume such files already have a correct timestamp, since it may improve performance by processing fewer files ⚑
  • --skip-older-than-commit, -N β€” ignore files older than the timestamp it would be updated to. such files may be considered "original", likely in the author's repository 🧚
  • --unique-times β€” set the microseconds to a unique value per commit. this lets you tell apart changes that would otherwise have identical timestamps, since git's time accuracy is in seconds πŸ”¬
  • --version, -V β€” show the program's version number and exit πŸŽ€

✨ KNOWN ISSUES ✨

bestie these are the real ones, read them fr fr 😭
  • 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 πŸ‘‘


and that's the whole page bestie, you ate that 🫢 this beauty is dated 2022-07-27 and it lives under the GIT-RESTORE-MTIME(1) banner, mwah πŸ’…βœ¨