GitStatusMonitor increase minimum time between updates

[gerhardol]

Fixes #8871

Proposed changes

Increase the time between git-status runs from 5s to 30s

So for instance when building, git-status runs every 30s

If there has been no changes and git-status has not run in 30s,
git-status will run in about one second as now

This affects:

• Commit button count
• artificial commit summary and tooltip
• left panel status and tooltips (added in 3.5)
• submodule menu drop down

The use case with most impact as I see it is if you save one file in the editor (git-status is triggered quickly), then you select another file in the editor already edited and save that, then the status will be updated in about 30s instead of about 5s.

Test methodology

manual

---

✒️ I contribute this code under The Developer Certificate of Origin.

[codecov]

Codecov Report

Merging #8886 (acddf06) into master (b6905f1) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8886   +/-   ##
=======================================
  Coverage   56.03%   56.03%           
=======================================
  Files         922      922           
  Lines       65944    65944           
  Branches    12070    12070           
=======================================
  Hits        36951    36951           
+ Misses      25985    25984    -1     
- Partials     3008     3009    +1     

Flag	Coverage Δ
production	43.25% <ø> (-0.01%)	⬇️
tests	94.83% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[gerhardol]

@gitextensions/git-extensions-source Any objections to this change and to include it in 3.5?

For 3.5 we could maybe just decrease the periodicity, set it to maybe 15 s instead if 30 s seem too much.
For master we could implement some more advanced back-off algorithm if this is not good enough.

[RussKie]

Once merged I'll cherry pick this into 3.5

[mstv]

For 3.5 we could maybe just decrease the periodicity, set it to maybe 15 s instead if 30 s seem too much.

I am afraid, 30 s could be too long. I guess I must run it for about a week.

For master we could implement some more advanced back-off algorithm if this is not good enough.

Yes, wasn't there a suggestion for doubling the delay up to a limit? But perhaps it is not necessary. Testing with fixed 30s...

[gerhardol]

For 3.5 we could maybe just decrease the periodicity, set it to maybe 15 s instead if 30 s seem too much.

I am afraid, 30 s could be too long. I guess I must run it for about a week.

For master we could implement some more advanced back-off algorithm if this is not good enough.

Yes, wasn't there a suggestion for doubling the delay up to a limit? But perhaps it is not necessary. Testing with fixed 30s...

It got too complex for a quick solution, there are already some delays to wait a little time after exlplicit refreshes and file changes so that is maybe for later.
I rather improve the functionality (not creating the sidepanel tree for instance).

I choose 30s as that was matching a few scenarios with changing one file, realize that I needed to change another, do the change and check status. It is kind of the longest time I can wait staring at the screen.
This can be changed to something smaller (but not larger) from my point of view.

[mstv]

Finally, I have understood why it takes so long until the number of changed files for artificial commits is updated after un/staging in FormBrowse. Now it takes half a minute.
We should force an update after these operations.

[gerhardol]

Finally, I have understood why it takes so long until the number of changed files for artificial commits is updated after un/staging in FormBrowse. Now it takes half a minute.
We should force an update after these operations.

It could take five minutes before if the change was done worktree<->index.
I submitted #8894 for RevDiff changes.
Maybe the same should be done for changes in other forms too.

And I propose the delay time is set to 15 s in 3.5.

[gerhardol]

This PR requires #8894 (and maybe a few similar tweaks in Browse, RevFileTree)
Align this with #8902 too - less important with that PR

[mstv]

It worked well for me with #8894.