Yes, I know about it but it does not work completely for me:

Examples:
$ git update-index --no-assume-unchanged saves/* && touch saves/* &&
time git status saves/*
20 seconds reading file contents that did not actually change.

$ git update-index --assume-unchanged saves/* && touch saves/* && time
git status saves/*
0,5 seconds, that's good, the assume-unchanged flag works as intended.

$ git update-index --no-assume-unchanged saves/* && time git status saves/*
20 seconds again. This is only a partial solution, as I have to remove
the assume-unchanged flag eventually.

'git update-index --refresh' does not improve:
$ git update-index --assume-unchanged saves/* && touch saves/* && git
update-index --refresh saves/* && git update-index
--no-assume-unchanged saves/* && time git status saves/*
20 seconds again.

'git update-index --really-refresh' does not improve:
$ git update-index --assume-unchanged saves/* && touch saves/* && git
update-index --really-refresh saves/* && git update-index
--no-assume-unchanged saves/* && time git status saves/*
20 seconds again.

The problem with the assume-unchanged flag for me is that git ignores
the mtime stored in the index, and when commands like 'git status' or
'git commit saves' have to check the contents then they have to reread
the file.

I need it not to ignore the mtime but to store the proper mtime
without rereading the files. A command like 'git checkout --mtime
$mymtime HEAD -- $myfile' in a clean working copy would be able to
store the mtime in the index without touching the contents of the
file. We can use GIT_COMMITTER_DATE for 'git commit', another
environment variable could make sense here too.


On Sun, Jan 6, 2019 at 1:53 PM Philip Oakley <philipoak...@iee.org> wrote:
>
> 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.

Reply via email to