threads / discuss / 50161

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

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

## tl;dr

4 messages between Jan 5, 2019 and Jan 9, 2019.

replies: 3people: 3as markdown or json

Philip Oakley· Jan 5, 2019, 20:35 UTC · lore

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 <git@vger.kernel.org>" (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:

Show 25 quoted lines

> 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.

Daniel Fanjul· Jan 5, 2019, 21:44 UTC · re: Philip Oakley · lore

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.

Konstantin Khomoutov· Jan 9, 2019, 16:20 UTC · re: Daniel Fanjul · lore

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

Show 7 quoted lines

> 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/

Daniel Fanjul· Jan 9, 2019, 22:57 UTC · re: Konstantin Khomoutov · lore

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.