On 2022-01-25 at 14:30:11, Michael Herrmann wrote: > Andreas Schwab wrote: > > > See the core.trustctime config. > > This sounds very promising. It also fixes the problem in my > preliminary tests. Are there known drawbacks to changing this setting > to false? I haven't yet noticed a performance impact. The index holds a bunch of information on files and checks that information to see whether the file has changed. If the stat information changes, then the file is marked dirty and may be re-read. The option above and core.checkStat control which information is included. When you do "git reset --hard" and there's no change to the file in the index, Git happens not to rewrite it in the working tree. This is an implementation detail and isn't guaranteed, but that's why things happen to be working here. The downside to restricting what's in the index is that Git can miss changes. For example, with core.trustctime turned off, a program that modifies a file without changing its size but resets it to have the same mtime would probably result in Git missing those changes. It shouldn't result in a performance difference, but it could theoretically result in a correctness difference. You may decide the tradeoff is worth it, however. > Randall wrote: > > > I think there are more use cases here than are apparent > > The use case is Chromium's build process. It creates hard links from a > src/... to a gen/... directory. Some actions do `git reset --hard` in > src/. This updates the modification time because of the hard links - > even when there are no changes. That in turn leads to unnecessary > rebuilds. I have little control over the creation of the hard links. Thanks, this is helpful context and it explains why you'd want this behavior. If you're involved with the project, it may be helpful to point out to other project members that this occurs and suggest that the scripts avoid running "git reset --hard". For example, it may be easy to avoid if "git status --porcelain" produces empty output. I've heard stories about Chromium's build times and I'm sure such an optimization would be welcome. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
