Hi Daniel
(trimmed the cc, removing the Git List as they won't have seen these
HTML emails.. I'd only added it to confirm their address and forgot to
remove it, doh!)
Yes, the 'git update-index --assume-unchanged' is confusing because
actually it is a _user_ promise not to change things, so that git can be
parsimonious in the checking of the file status, rather than telling Git
not to look at the file ! There is a thread I'm contributing to about
getting the man page to be more plain speaking about that
I've just had a re-read of the git update-index man page
https://git-scm.com/docs/git-update-index#_using_refresh and it looks
like the --refresh option is what you need as soon as you update the mtimes.
Check all occurrences of --refresh on the man page to see the
interaction with other flags, and the quiet/error options.
See what you think and have a try. Hope it helps.
Philip
On 05/01/2019 21:44, 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.
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.
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
