Re: [git-users] git checkout file with custom mtime

Daniel,


Do you use the Git LFS (Large File System) add-on?, are you on Windows 
or Linux?, and what tools need mtime (or is it something about the 
process of using the tool..)?

The Git viewpoint is that the mtime shouldn't be important for the 
version storage & control aspects, though it maybe for the external 
compiler tooling, so they do tend to try to keep the mtime/ctime consistent.

I'm not aware of specific capability to do what you ask, but it may be 
worth discussing this on the git mailing list "Git List 
[off-list ref]" (which only accepts 100% plain text, no HTML, 
messages). The mailing list archive is at 
https://public-inbox.org/git/?q= where you can search for mtime/ctime 
discussions.

There will be a Git developer conference at the end of the month, so it 
is worth raining it soonish, even if it becomes an add on the fires via 
a post checkout hook that updates the mtimes from a stored file of 
'true' mtimes (plus updates the index's view of those mtimes.

Philip

On 05/01/2019 13:33, Daniel Fanjul wrote:

Hi all,

I have some large files tracked in git and I have to track their mtime 
because of some legacy software. With another tool I save and restore 
their mtime. When I restore their mtime git status rereads the files 
to update the mtime in the index. I would like to improve that because 
there are too many files, the whole I/O is too slow and the whole 
process is triggered too often.

I would like a way to tell git to checkout a file and set a given 
mtime at the same time so the index is updated with the mtime but the 
file is not rewritten because the working copy is clean. This would 
solve my problem. Do you know a way to do this?

Do you know any other way to handle this properly?

Thanks in advance, and happy new year,
Daniel.
-- 
You received this message because you are subscribed to the Google 
Groups "Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to git-users+unsubscribe@googlegroups.com 
<mailto:git-users+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

I'm on Ubuntu. I do not use LFS. I track mods and saved games of
Skyrim with git, TESV.exe sorts the saved games only by their mtime. I
know it is not the most usual use case for git.

I agree with that viewpoint and I like the way git works right now, I
do not want to change that. Checking out the saved games and then
fixing the mtime works but forces a lot of unneeded I/O.

I forgot to mention that 'git update-index --assume-unchanged' does
not solve this well enough. Eventually 'git status' rereads the file
when that flag is removed. A better way for my use case would be being
able to set the proper mtime without forcing a rehash of the file that
yields the same object.

Thanks for your reply.

On Sat, Jan 05, 2019 at 10:44:47PM +0100, Daniel Fanjul wrote:

I'm on Ubuntu. I do not use LFS. I track mods and saved games of
Skyrim with git, TESV.exe sorts the saved games only by their mtime. I
know it is not the most usual use case for git.

I agree with that viewpoint and I like the way git works right now, I
do not want to change that. Checking out the saved games and then
fixing the mtime works but forces a lot of unneeded I/O.

You might find this overview of git-annex vs git lfs useful:
https://lwn.net/Articles/774125/

Also see this recent thread on the Git list:
https://public-inbox.org/git/79fd2b4e-243c-a9f5-3485-2954fb0f50ef@aixigo.de/

The mtime of the files in my working copy change when I amend or
rebase or checkout different branches or in general when I use git
commands. I carefully store the mtime when these files are generated
or overwritten and restore it when it is going to be read. The tool I
use is https://packages.ubuntu.com/bionic/metastore and does not have
stale information.

I do not know how git lfs will work here, it handles large contents
but I doubt it will handle the mtimes as I need.