[Feature Request] Add an option to disable `git status` check on focusing Fork

[mtschoen-unity]

For very large repos, git stats can take a non-trivial amount of time. Because of this, whenever I use Fork for such a repo, I have to wait a little bit every time I focus Fork before I do anything that needs to modify the index. I frequently hit the index.lock exists dialog, and it generally makes me prefer CLI to Fork for these repos. I can see why Fork does this, but I would love to have an option to disable this behavior (ideally on a per-repo basis) and expose a manual "refresh" or "update status" button/hotkey so I can manually trigger updates as needed.

Thanks in advance! :)

[mtschoen-unity]

Hey there @DanPristupov have you had a chance to look at this? For an open-source example, try cloning Chromium and looking at it with Fork. Fair warning... you'll need ~50GB free to even clone the thing! It's a pretty good stress test, and I'm sorry to say it basically renders Fork unusable. Opening the window for the first time takes ~20s, and every time I refocus it's ~8-10s before I can do anything like stage files or commit them, and this is on an M1 Max. Browsing the history is still useful, but even then, big diffs will choke the UI, and I often can't view far enough back in the history before the log is just truncated, even if I'm using filtering. For example, trying to view this branch from 7 months ago in Fork just silently fails, because the head commit is too far back. Here's what tends to happen with me when I try to use Fork on big repos:

0. I already have "fetch remotes automatically" disabled since it's a bit spammy, even on smaller repos
1. Open a large repo in Fork
2. Observe spinner due to status update. I know in this state I can't do much because the repo is locked
3. Switch tasks to another window to read Slack, do something quick while I wait for Fork to load the repo in the background
4. Switch tasks back to Fork... it queries status again
5. Hope my ADHD brain doesn't immediately switch to some other window because I see a loading spinner
6. Repeat...

If I could just let it load once, switch tasks, and then come back to Fork and do work, it would be totally fine. All I would need is a manual "refresh" button in the UI to get status when I need it. The initial status check when the window opens could still be automatic, and I think it would make sense for this behavior to be opt-in. For most repos, the status check is quick and this isn't an issue. I know, maybe calling it "unusable" is harsh, bit the end result is that I do as much as I can from CLI, which means I rarely open fork on large repos anymore.

[DanPristupov]

Add an option to disable git status check on focusing Fork

We can try to disable status update on activation, but I guess it's not as simple as it sounds and probably won't make a big difference because git status will be called after each operation affecting the working directory (commit, checkout, merge, etc) anyway.

try cloning Chromium and looking at it with Fork.

I regularly test Fork on Chromium. It's my main testing repository. It's not fully usable yet, but we are getting there. Right now we are working on major performance improvements but sadly not in the git status related area.

I also work on an M1 Max and here is the result of the benchmark:

Opening the window for the first time takes ~20s, and every time I refocus it's ~8-10s before I can do anything like stage files or commit them, and this is on an M1 Max.

For me it takes much less:

https://github.com/fork-dev/Tracker/assets/618115/7c6c1fb8-cda4-481f-a2dd-05be6abc0f63

1. • time git status --porcelain --untracked-files=all takes 3.5-4 seconds on my computer.
   • time git status --porcelain --untracked-files=no takes 2.5 seconds on my computer.

So, consider to hide untracked files:

2. Consider to hide tags: View -> Hide tags. Soon, this will not be needed, but for now it helps.

3. Run git gc

For example, trying to view this branch from 7 months ago in Fork just silently fails, because the head commit is too far back.

Yes, I confirm this. We need to change the internal architecture to support this use case.

I also noticed, that Fork updates the list of changes files (i.e. git status) when switching between commit list and working directory view. We need to improve that.

P.S. It's not really related, but some time ago I investigated why exactly git status in the Chromium repo is so slow and it turned out that the majority of slowness comes from just a few folders in the third_party directory. AFAIK, they are responsible for >80% of the git status time.

[mtschoen-unity]

We can try to disable status update on activation, but I guess it's not as simple as it sounds and probably won't make a big difference because git status will be called after each operation affecting the working directory (commit, checkout, merge, etc) anyway.

That's a fair point. Could we also make those status calls optional as well? 😅 I'm personally a fan of Refresh buttons in general, rather than this "automagic" pattern where everything refreshes automatically that's all the rage these days. Maybe I'm just a grumpy old man. 😉

I think it's unavoidable that large repos will take a long time to update status, etc. and I'll always want a way to avoid status checks and any other git operations where possible. I can see why you update status after every operation, since otherwise Fork might try to act on stale data and break stuff. But for "power users" maybe this is acceptable? Even if it blocked me from doing more commits or something until I hit refresh, I'd still prefer to have direct control.

Ultimately, the issue I'm finding here is that focusing/unfocusing the window is not something I'm used to taking time. I switch tasks all the time and it's really hard to remember not to switch out of Fork until I'm doing working with it. In fact, it's pretty much an instinct when I see any kind of progress bar to hit alt-tab and see what else I can do while I'm waiting.

I regularly test Fork on Chromium. It's my main testing repository.

That's great to hear! You can probably assume from my username that I'm working on a different large repo, and we have our own optimization problems to contend with. FWIW, perf on Chromium is worse than ours, so it's still a good stress test! I admire the goal of trying to improve the performance of git status, but I think it's inevitable that perf will regress, or there will be some good reason why you can't get it down below the magical 500ms "so fast you don't notice" UX benchmark. From my POV, providing an option to take manual control (especially if it's something I can enable for specific repos) is the ideal solution. Even if it's just some undocumented settings file that puts fork into a special mode (just for me? 🥺) that would help.

[DanPristupov]

Can you show the benchmark results (Repository -> Benchmark) or send them to support@fork.dev? Timings would help me to understand the problem better.

[mtschoen-unity]

Just sent them over. Thanks again for taking the time to look at this!

[mtschoen-unity]

Another thought while working with Fork in a large repo... I think the frustration also comes from the fact that I can try to do things like stage files while the status check is in progress, but they will just fail because the repo is locked. If the button was grayed out, at least I wouldn't also have to dismiss the error window. Or (even better) if actions were queued when Fork is in this state, I could be productive while the status check is going.