Configuration to fetch origin at launch

[ghiboz]

should be good have a setting (like the autofetch interval) to make a fetch at the startup of the ap

[love-linger]

Currently, it can be done by simply modify one line:

diff --git a/src/Models/AutoFetchManager.cs b/src/Models/AutoFetchManager.cs
index 313f5f64..2e1fb78c 100644
--- a/src/Models/AutoFetchManager.cs
+++ b/src/Models/AutoFetchManager.cs
@@ -97,7 +97,7 @@ namespace SourceGit.Models
             {
                 IndexLockFile = Path.Combine(gitDir, "index.lock"),
                 Cmd = new Commands.Fetch(repo, "--all", true, false, null) { RaiseError = false },
-                NextRunTimepoint = DateTime.Now.AddMinutes(Convert.ToDouble(Interval)),
+                NextRunTimepoint = DateTime.Now,
             };

             lock (_lock)

It removes the delay for the first time running background auto-fetching.

But I'm not sure it is the right way since there's not UI/UX notification that shows a background auto-fetching task is running and the progress of that task is also invisible.

[joesponde]

When auto-fetch activates regularly in the background with current version, there is no UI/UX notification, as far as I observed. So, it should not be "bad" to do it at launch time. If running the autofetch directly at launch time may seem risky or a source of startup slowness, it may be delayed with a couple or a few dozens of seconds?

[love-linger]

When auto-fetch activates regularly in the background with current version, there is no UI/UX notification, as far as I observed.

Yes, but it is very important to let users known that there's already a background fetching task running to avoid user doing it manually. For example, I'm a game developer, and after I opened the UnrealEngine repo, it takes a very long time before the first auto-fetching really completed. The key point is that I don't know if it has been completed or if I can do other jobs.

[love-linger]

Actually, I never use the Auto Fetch Remote feature...

[ghiboz]

When auto-fetch activates regularly in the background with current version, there is no UI/UX notification, as far as I observed.

Yes, but it is very important to let users known that there's already a background fetching task running to avoid user doing it manually. For example, I'm a game developer, and after I opened the UnrealEngine repo, it takes a very long time before the first auto-fetching really completed. The key point is that I don't know if it has been completed or if I can do other jobs.

I think the better way is to expose a flag in the preferences

[joesponde]

Yes, but it is very important to let users known that there's already a background fetching task running to avoid user doing it manually. For example, I'm a game developer, and after I opened the UnrealEngine repo, it takes a very long time before the first auto-fetching really completed. The key point is that I don't know if it has been completed or if I can do other jobs.

I see, in this use case, auto fetch may be more complex to deal with. If I correctly understand, this use case happens when repositories are very large and very active, like with companies using mono repos (every applications, tools, libraries are stored in the same and unique repository).

For instance, in my case, I work with moderately active repositories, auto-fetch is a more than "nice to have" feature, its a highly appreciated feature.

To come back to the problematic use case, we may imagine that the first auto-fetch would start at launch time, and if the user manually clicks on the fetch button whereas auto-fetch is still going on:

• either a popup warning message opens and nothing is done,
• or the fetch subpanel is displayed (even in the case of Ctrl + Click) and the OK button remains disabled as long as the background fetch is going on, with a message in the subpanel indicating that there is a fetch in progress.

[love-linger]

I do NOT like the Auto Fetch Remote feature...

For large repositories, auto fetching changes from remote after repository is opened will lead to a bad experience, since git will prevent other operations that will modify the index if index.lock file exists. And as I said, in current implementation of auto fetching, we do NOT known if the background fetching task is completed, and also can NOT stop it to do some other emergency jobs.

Unless there is a good UI/UX design, I'll not consider to add this feature.