* Re: [git-users] git checkout file with custom mtime [not found] <951cafaa-877b-4815-862f-5ffc43e6976a@googlegroups.com> @ 2019-01-05 20:35 ` Philip Oakley 2019-01-05 21:44 ` Daniel Fanjul 0 siblings, 1 reply; 4+ messages in thread From: Philip Oakley @ 2019-01-05 20:35 UTC (permalink / raw) To: git-users, Daniel Fanjul, Git List 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: > 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [git-users] git checkout file with custom mtime 2019-01-05 20:35 ` [git-users] git checkout file with custom mtime Philip Oakley @ 2019-01-05 21:44 ` Daniel Fanjul 2019-01-09 16:20 ` Konstantin Khomoutov 0 siblings, 1 reply; 4+ messages in thread From: Daniel Fanjul @ 2019-01-05 21:44 UTC (permalink / raw) To: git-users; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [git-users] git checkout file with custom mtime 2019-01-05 21:44 ` Daniel Fanjul @ 2019-01-09 16:20 ` Konstantin Khomoutov 2019-01-09 22:57 ` Daniel Fanjul 0 siblings, 1 reply; 4+ messages in thread From: Konstantin Khomoutov @ 2019-01-09 16:20 UTC (permalink / raw) To: git-users; +Cc: Git List 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [git-users] git checkout file with custom mtime 2019-01-09 16:20 ` Konstantin Khomoutov @ 2019-01-09 22:57 ` Daniel Fanjul 0 siblings, 0 replies; 4+ messages in thread From: Daniel Fanjul @ 2019-01-09 22:57 UTC (permalink / raw) To: git-users; +Cc: Git List 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-01-09 22:57 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <951cafaa-877b-4815-862f-5ffc43e6976a@googlegroups.com> 2019-01-05 20:35 ` [git-users] git checkout file with custom mtime Philip Oakley 2019-01-05 21:44 ` Daniel Fanjul 2019-01-09 16:20 ` Konstantin Khomoutov 2019-01-09 22:57 ` Daniel Fanjul
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).