Re: A puzzle: reset --hard and hard links

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]