{"thread":{"id":"66169","subject":"mtime is not restored after --autostash","startedAt":"2026-08-13T18:10:23Z","lastAt":"2026-08-13T18:10:23Z","messageCount":1,"participants":["Jos van den Oever"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"550552","messageId":"40429f46-ff82-4149-8204-2d4ab1925117@vandenoever.info","threadId":"66169","inReplyTo":null,"subject":"mtime is not restored after --autostash","fromName":"Jos van den Oever","fromEmail":"jos@vandenoever.info","sentAt":"2026-08-13T18:02:28Z","receivedAt":"2026-08-13T18:10:23Z","isPatch":false,"body":"Dear git developers,\n\nWhen git pull, merge, and rebase are used with --autostash and modify \nthe current working directory, the mtime of files that are restored \n(stash apply) are set to the current time, even when the files have not \nchanged.\n\nIn my understanding, git usually does nothing to the mtime of files so \ntheir mtime is set to the current time when they are written instead of \ne.g. the mtime of the commit date that is checked out. This ensures that \nbuild systems will run actions for which the changed file is an input.\n\nWhen using --autostash there is the opportunity to restore the mtime \nthat the dirty file had before the git command. This can save a lot of \nwork for the build system.\n\nThere is another use case where restoring the mtime is useful: using git \nfor unattended syncing of files. A system that checks in files \nautomatically, after a cooling off period, could use the mtime as the \nauthor date of the commit. If --autostash changes the mtime, that date \nis wrong. Such a system could work around this by keeping track of the \nmtimes of dirty and new files and restoring them itself instead of \nrelying on --autostash to do so.\n\nBest regards,\nJos van den Oever\n\n"}]}