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.


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.

Reply via email to