4 ms·
Oh, I just meant caching within the lifetime of a single git command's execution. As it stands, when you run "git status", the git executable goes through each
by teraflop 5y ago
Oh, I just meant caching within the lifetime of a single git command's execution.
As it stands, when you run "git status", the git executable goes through each directory in your working copy, lists all of its directory entries, and then immediately afterward calls open() to see if a .gitignore file exists in that directory -- even if there wasn't one in the list it just read.
That's what I meant by saying that in principle, there's no reason git couldn't just cache the file's presence/absence on its own, just for those few microseconds (maybe "cache" was a poor choice of words). In practice, I can understand that the implementation complexity might not be worth it.
- Groxx 5y agoah, lol. yeah, that's a good point, that scenario could definitely be smarter - I wasn't thinking about it listing the directory first. plus the time between list and "look again for .gitignore" is small enough that any inconsistencies could very reasonably be labeled an acceptable resolution to a race between git and other file system changes.