Re: [PATCH] git-gui: Perform rescan on window focus-in

> Hi,
> 
> On Sat, 3 Aug 2019, Pratyush Yadav wrote:
> 
>> On 8/2/19 6:09 PM, Johannes Schindelin wrote:
>>>
>>> On Fri, 2 Aug 2019, Pratyush Yadav wrote:
>>>
>>>> On 8/1/19 1:12 AM, Johannes Schindelin wrote:
>>>>>
>>>>> I would be _extremely_ cautious to base an argument on one
>>>>> particular setup, using on particular hardware with one
>>>>> particular OS and one particular repository.
>>>>>
>>>>
>>>> Agreed. That's why I asked for benchmarks from other people.
>>>> Unfortunately, no one replied.
>>>
>>> What stops _you_ from performing more tests yourself? There are tons
>>> of real-world repositories out there, we even talk about options for
>>> large repositories to test with in Git for Windows' Contributing
>>> Guidelines:
>>> https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md#performance-tests
>>
>> I thought the point was to not base all data off a single setup?
> 
> You misunderstood what I was saying: a single setup is bad, and you can
> make it moderately better by testing _at least_ with a moderately-sized
> repository [*1*] in addition to git.git.
> 
> So yes, it would still not be enough to test with, say, the git.git
> _and_ the Chromium repository _only_ on your setup, but if not even you
> can be bothered to test with more than one small repository, how can you
> possibly expect anybody else to add more testing?

> 
>> [...]
>>> I wonder, however, whether you can think of a better method to
>>> figure out when to auto-refresh. Focus seems to be a low-hanging
>>> fruit, but as you noticed it is not very accurate. Maybe if you
>>> combine it with a timeout? Or maybe you can detect idle time in
>>> Tcl/Tk?
>>
>> Hm, I don't see a better alternative than file system watches.
>> Timeouts are a heuristic that can potentially be problematic.
> 
> Let me stress the fact that I suggested a timeout _in addition_ to the
> focus event?

> 
> Yes, using a timeout on its own is stupidly problematic. That's why I
> did not suggest that.
> 
>> If you do a refresh too frequently, you hog up the user's resources
>> for little benefit.
> 
> Indeed. You want to find a heuristic that catches most of the cases
> where files were changed, while at the same time not even _trying_ to
> refresh automatically when probably nothing changed.

> 
>> You don't refresh frequently enough, then sometimes the user sees an
>> updated view, sometimes a not-updated view. This inconsistency, if not
>> fine tuned properly, can prove detrimental to UX.
> 
> Right, exactly. And of course, since you are not changing your own Git
> fork only, but the Git that is the one that most users will use, you
> will have to consider carefully in which direction to strike the balance
> by default.

> 
> I would contend that you should err on the side of _not_ refreshing, as
> that would probably affect more users negatively than the opposite.
> 
> Ciao,
> Johannes
> 
> Footnote *1*: I don't expect you to test with the largest repositories,
> as you are unlikely to have access to anything approaching the size of
> the largest Git repository on the planet:
> https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/
>