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

[Pratyush Yadav <me@yadavpratyush.com>]

+Junio

On 8/1/19 1:12 AM, Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 29 Jul 2019, Pratyush Yadav wrote:
> 
>> On 29/07/19 7:58 AM, Mark Levedahl wrote:
>>> On 7/28/19 6:49 PM, brian m. carlson wrote:> On 2019-07-28 at
>>> 22:10:29, Pratyush Yadav wrote:
>>>>> The function is not documented, and I only started spelunking
>>>>> the code a couple days back, so I'll try to answer with what I
>>>>> know. It might not be the full picture.
>>>>>
>>>>> Running git-gui --trace, these commands are executed during a rescan:
>>>>>
>>>>> /usr/lib/git-core/git-rev-parse --verify HEAD
>>>>> /usr/lib/git-core/git-update-index -q --unmerged --ignore-missing --refresh
>>>>>
>>>>
>>>> Great. This sounds like a well-reasoned change. I'll let other folks who
>>>> use git-gui more chime in to see what they think as well.
>>>>
>>>
>>> I'm assuming this does what is currently done by F5.
>>> A simple rescan from git-gui in the git repository takes about 8 seconds on
>>> my corporate laptop running Windows, making this happen on change of window
>>> focus is definitely not a friendly change from my view point.
>>>
>>
>> This is a Windows problem maybe? On my Linux machine with an almost dead hard
>> drive, it takes under 10ms to do a refresh on the git repository (which has
>> about 56,000 commits).
> 
> 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.

I am worried about exactly this problem that other users will have 
performance problems. I usually reserve judgment till I see some actual 
benchmarks, but since in this case we aren't getting any, it is probably 
better to err on the side of caution.

> When it comes to repositories that are worked on actively, git.git is
> not actually a representative example, it is way smaller than what users
> deal with.

Out of curiosity, what would you consider large enough? The Linux kernel 
(855,753 commits as of writing this)?

> 
> You might be one of those developers privileged enough to have a fast
> computer. Trying to extrapolate from such a vantage point does the rest
> of us Git users a big disservice.

Yes I have a pretty powerful machine in the processor department, but I 
have a rather slow hard disk. I assumed most people would have faster 
hard disks than me, but in hindsight, that might not be a good 
assumption to make.

> 
> At this point, I am gently inclined against the presented approach, in
> particular given that even context menus reportedly trigger the re-scan
> (which I suspect might actually be a Linux-only issue, as context menus
> are top-level windows on X11, at least if I remember correctly, and I
> also seem to remember that they are dependent windows on Aqua and Win32,
> just to add yet another argument against overfitting considerations onto
> a single, specific setup).

All right, the patch in its current state can't fly. So what is the 
correct way to do this? I see the following options:

1. Add this as an option that is disabled by default, but people who 
don't mind it can enable it. This is the easiest to implement. But I 
leave it to you and Junio (and anyone else who wants to pitch in :)) to 
decide if it is a good idea.

2. Watch all files for changes. Atom does this for their git gui [0]. We 
can probably use watchman [1] for this, but this adds another external 
dependency.

3. Leave this feature out. I of course don't like this option very much, 
and will probably have to run a fork, but if it is better for the 
project, it is better for the project.

Which option do you want to go with?

Naturally, my favourite option is number 1 because it will be the 
easiest to implement ;)

[0] 
https://discuss.atom.io/t/how-does-atom-refresh-git-state-when-some-external-editor-changes-it/67210
[1] https://github.com/facebook/watchman

-- 
Regards,
Pratyush Yadav