Yes, that's exactly why I have the idea: We often realize very late when someone has made a change on a share. That's why it would be great if SmartGit made this information available to users.

But your comment probably points to a potential problem.
This is exactly why it would be good to
a) be able to switch such a smart function on/off in general
b) And then presumably per repository, whether the smart function should analyze it

Thank you for this tip! The function is useful and a good start.

From a smart tool, I would expect proactive user support. This means: I shouldn't have to execute a command to mark all repositories that no longer exist locally; instead, a subtle status icon should be automatically displayed as soon as a repository no longer exists locally.

In other words: It would be great if, under "Smart Functions" in the settings, one could enable that the repositories display useful additional information, such as:

• Does it still exist locally?
• Does it still exist on the server?
• Were there changes on the server?
• Were there local changes?
• …?

(The reason for displaying local changes is that employees sometimes forget to check in their changes and transfer them to the server. If users see this status with an icon, they will notice it very quickly because they see the repository list repeatedly.)

By the way, that would be a USP (unique selling proposition), a "Alleinstellungsmerkmal", that would excite us because it is useful and simplifies work and overview.

Thanks a lot, kind regards,
Thomas

Hello Daniel

I have sent a screenshot below of which repository overview it would be useful to see if changes have been made.

> Should this be a Repo Level or System wide setting?
This is an extremely good question!… after some thought, I came to this conclusion:

❯ The system load is probably not so big that it would interfere if SmartGit checks all repositories

❯ If the result of this background job is displayed discreetly in the repositories, the display would probably not be disruptive.

But it could be that there are SmartGit customers who want to keep the control and prefer to be able to set which Repo the background scanner should check.

Therefore, a repo level setting would probably be the safer option so that no SmartGit customer gets annoyed.

Thanks a lot, kind regards,
Thomas

Thank you, Daniel, for your question :-)
I was thinking of this repository list:

Thanks a lot, kind regards,
Thomas

I missed one check which should be done:

2.4: Check, if the Repository still exists (local and the git server)

OK, OK, I see it: My description does not explain the functions independent of each other, too.

But I think this concept for a description is still much more useful:

• The user can read through the explanation fluently and understand the difference between the two functions at the end.
  
• Therefore, the user can make a decision and is pretty sure he got the right one :-)