You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following data is based on my local project tests. Please note that actual times may vary depending on device performance and repository size:
Slow startup: Fork takes about 10s to launch, while GitComet takes around 17s.
Unnecessary loading animation: Every time I switch the app from background to foreground, the tab shows a loading spinner for about 10s, even when I have no uncommitted files.
No command execution history: There's nowhere to view the Git command logs. It's unclear what command is actually running when I click a button (e.g., whether pull automatically fetches tags or other branches). Having an execution history would be much better.
Timeout on pull rebase: For my project, only a few branches are fetched and no tags are pulled (which I think is normal for large repos). However, when I click "pull rebase," it runs for a long time and eventually times out. Since I can't see the underlying command, I can't figure out the cause. Could you consider adding customizable pull options for this scenario? (Fork allows custom commands in its menu; I use git pull -r origin ${ref}, which works perfectly for my case.)
Thanks for the report @DaveBoy
Can you paste the environment details from GitComet Settings - Environment please.
17 seconds launch time sounds wrong - maybe there is something off or a bug.
What hardware do you have?
My repository is 40GB in size (with fewer than 10 branches currently checked out). I'm not sure if this is related to the issue.
when you focus GitComet window it scans for changed files, this is to ensure unstaged / staged sections show up to date information. Maybe the scanning is doing some extra work in your repository? Could there be there some git ignored files or something like that what is causing the scanning? Maybe lots of small files?
My repository contains a large number of files, including ignored build temporary files and unignored but committed resource files. However, I believe these are normal scenarios, so is it normal for it to take this long to scan?
The gitcomet software is the latest release zip version, which I just downloaded today. The repository is a private one, so it's not convenient to provide.
Regarding the startup duration issue, I think it might not be related to the repository, because after the first startup, the repository code was not loaded, and instead, a screen appeared asking me to select and open a repository. Perhaps it is related to the resource usage of my device, but the relevant comparison was conducted at the same time for the same repository. If logs are needed, please let me know how to obtain them, and I will find time later to retest and provide the logs for troubleshooting.
My experience is that gitcomit is quote slow to start in Windows, too. Frist run is ~7 seconds to start up. If I close all repos, quit and restart it still takes ~3s to start - which I would consider too slow.
Are you guys able to do profiling to see where its slow? There is this evaluation branch #633 it could be checkout out to test if it makes startup faster for you
15. Are you guys able to do profiling to see where its slow? There is this evaluation branch #633 it could be checkout out to test if it makes startup faster for you
I recently tested gitcomet-v0.3.1-windows-x86_64-portable, and it took approximately 10 seconds to start, which was an improvement compared to version 0.3.0.
However, when launched alongside Fork, GitComet also starts much faster, reducing its startup time to approximately 13-15 seconds.
I'm not sure how to use this evaluation branch for performance analysis.
it seems gpui-ce compiles some shaders at the startup and we are not using any of them... I think I could just make them lazy loaded so we dont have to pay the cost in GitComet
It's great that version 0.3.2 shows some improvement during the initial startup, but subsequent launches are significantly faster. The speed improvements are definitely noticeable.
Furthermore, I noticed that switching back to the foreground no longer causes the spinning animation, which has significantly reduced my anxiety while waiting.
I'm unsure if there are any plans to adjust the other two items.
Specifically, regarding the "pull single branch" approach, this will determine whether I can actually use it. My project is unlikely to involve pulling from all branches or tags.
The history log simply provides a record of what actions were performed when a button was clicked, including any parameters used (e.g., whether tags were pulled). This is not essential, but it can be helpful when troubleshooting issues, such as long-running pulls that don't complete.
24. Could you @DaveBoy create separate issue for those two bullet points please. I would like to see if there is wider interest to have these implemented.
I'm closing now this issue as the main slowness is fixed
Activity
Havunen commentedon Oct 16, 2026
Thanks for the report @DaveBoy
Can you paste the environment details from GitComet Settings - Environment please.
17 seconds launch time sounds wrong - maybe there is something off or a bug.
What hardware do you have?
DaveBoy commentedon Oct 16, 2026
System
Build: GitComet v0.3.0
Git: git version 2.54.0.windows.1
Operating system: Windows 10 Pro
Kernel: 19045
Architecture: x86_64
CPU: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
Logical processors: 8
Total memory: 15.8 GiB
Graphics
Window system: Win32
Selected GPU: Intel(R) UHD Graphics
Graphics backend: DirectX 12
Rendering: Hardware
Driver: 31.0.101.2134
Driver details: Unavailable
DaveBoy commentedon Oct 16, 2026
My repository is 40GB in size (with fewer than 10 branches currently checked out). I'm not sure if this is related to the issue.
DaveBoy commentedon Oct 16, 2026
thinkpad T14
Havunen commentedon Oct 16, 2026
when you focus GitComet window it scans for changed files, this is to ensure unstaged / staged sections show up to date information. Maybe the scanning is doing some extra work in your repository? Could there be there some git ignored files or something like that what is causing the scanning? Maybe lots of small files?
Havunen commentedon Oct 16, 2026
This is official release build right?
Havunen commentedon Oct 16, 2026
Is the repository public so I could try it out?
DaveBoy commentedon Oct 16, 2026
My repository contains a large number of files, including ignored build temporary files and unignored but committed resource files. However, I believe these are normal scenarios, so is it normal for it to take this long to scan?
DaveBoy commentedon Oct 16, 2026
The gitcomet software is the latest release zip version, which I just downloaded today. The repository is a private one, so it's not convenient to provide.
Havunen commentedon Oct 16, 2026
Well 17 seconds to me sounds way too long
DaveBoy commentedon Oct 16, 2026
Regarding the startup duration issue, I think it might not be related to the repository, because after the first startup, the repository code was not loaded, and instead, a screen appeared asking me to select and open a repository. Perhaps it is related to the resource usage of my device, but the relevant comparison was conducted at the same time for the same repository. If logs are needed, please let me know how to obtain them, and I will find time later to retest and provide the logs for troubleshooting.
dflock commentedon Oct 19, 2026
My experience is that gitcomit is quote slow to start in Windows, too. Frist run is ~7 seconds to start up. If I close all repos, quit and restart it still takes ~3s to start - which I would consider too slow.
Havunen commentedon Oct 19, 2026
I believe this is not about repository but maybe there is something else in the startup specific to windows OS.
Have you tried GitComet 0.3.1 is it still the same? GPU usage should be way less at least now
Havunen commentedon Oct 19, 2026
Are you guys able to do profiling to see where its slow? There is this evaluation branch #633 it could be checkout out to test if it makes startup faster for you
dflock commentedon Oct 20, 2026
I'm already running 0.3.1
DaveBoy commentedon Oct 20, 2026
I recently tested gitcomet-v0.3.1-windows-x86_64-portable, and it took approximately 10 seconds to start, which was an improvement compared to version 0.3.0.
However, when launched alongside Fork, GitComet also starts much faster, reducing its startup time to approximately 13-15 seconds.
I'm not sure how to use this evaluation branch for performance analysis.
Havunen commentedon Oct 20, 2026
Ok, so this issue is still valid then.
Havunen commentedon Oct 20, 2026
it seems gpui-ce compiles some shaders at the startup and we are not using any of them... I think I could just make them lazy loaded so we dont have to pay the cost in GitComet
Havunen commentedon Oct 22, 2026
The startup time should be fixed now on Windows OS, can you guys confirm please.
0.3.2 https://github.com/Auto-Explore/GitComet/releases/tag/v0.3.2
dflock commentedon Oct 22, 2026
This seems fixed! First run was still slow at ~6s, but after that, pretty instant!
DaveBoy commentedon Oct 23, 2026
It's great that version 0.3.2 shows some improvement during the initial startup, but subsequent launches are significantly faster. The speed improvements are definitely noticeable.
Furthermore, I noticed that switching back to the foreground no longer causes the spinning animation, which has significantly reduced my anxiety while waiting.
I'm unsure if there are any plans to adjust the other two items.
Havunen commentedon Oct 23, 2026
Could you @DaveBoy create separate issue for those two bullet points please. I would like to see if there is wider interest to have these implemented.
I'm closing now this issue as the main slowness is fixed
DaveBoy commentedon Oct 27, 2026
Okay, I have created two more issues.
#678 #677