Joey Hess wrote: > Jeff King wrote: > > Yeah, it is going to be painful on a cold cache. But I wonder whether > > your workflow would really permit the "reset" thing to make a > > difference. That is, are you doing "git reset -- file" from a cold > > cache, and then doing _nothing_ else with git? Because while yes, it may > > be annoying for the "reset" to take 30 seconds, it's warming the cache > > so that the subsequent "diff" or "status" will take 29.1 seconds less. > > > > Which isn't to say I'm not sympathetic to the performance problems of > > large repos on a cold cache. But I'm not sure there's really a way > > around that. You're going to want to see the stat information eventually > > if you are doing anything meaningful with git, and once it's loaded, the > > warm cache delay isn't too bad. Trying to avoid it seems like a losing > > battle. > > Could be true in general. While I've gotten the reset out of this > workflow (realized I could just `git checkout HEAD file` and that would > also clear staged changes), in this case it was actually *unlikely* that > the cache would be unused, as I was resetting to throw unwanted changes > away. Typo, meant to say unlikly that the cache would be used. -- see shy jo
Attachment:
signature.asc
Description: Digital signature