Rescan Repositories should be aware of Workspace Default Clone Dir

[henry-js]

I believe there should be a general preferences bool to "Prefer Workspace Default Clone Dir"

• When enabled, Rescan Repositories should take the current workspace clone dir instead of the default clone dir
• Rescan Repositories should clear repository nodes before scanning. This will remove invalid entries

[goran-w]

I agree.

Workspaces don't use their configured Default Clone Dir as expected.

• A Workspace has its own Default Clone Dir, but the one used when scanning is (only) the global (redundant?) one! Instead, the global one could be used only if the Workspace has not configured a Default Clone Dir of its own.
• The Repositories list is the same, regardless of which Workspace we choose! Instead, it should start empty for a new Workspace.

BTW : the concept of (hierarchical) Groups in this view is slightly confusing, since Groups are auto-created from directories when (re-)scanning the Default Clone Dir but they can also be re-arranged freely (the latter makes them diverge from the "physical" folder-structure on disk).

[love-linger]

The Repositories list is the same, regardless of which Workspace we choose! Instead, it should start empty for a new Workspace.

Completely disagree with this view. The design purpose of Workspace in SourceGit is to group the opened repositories and quickly switch between any Workspaces.

You can add any repo (open another repo that not added to current workspace) to current workspace at any time. There's no need to manage different repo list.

[goran-w]

Completely disagree with this view. The design purpose of Workspace in SourceGit is to group the opened repositories and quickly switch between any Workspaces.

Indeed, but for that to be really useful, I think the Workspaces should have their own separate lists of repositories?

You can add any repo (open another repo that not added to current workspace) to current workspace at any time. There's no need to manage different repo list.

The issue here is that when creating a new Workspace, it already has ALL the repos from the earlier/previous workspace in its repositories-list. So when switching between Workspaces, there's no difference seen on the Welcome page...

(This also makes the scanning of Default Clone Dir feature less useful. Consider two separate Workspaces configured with two separate Default Dirs - scanning in each Workspace would then make repos from both Dirs appear in the repositories-list for both Workspaces.)

BTW, if a lot of repos are added to the repositories-list, it becomes cumbersome to clear the list - since multi-selection is not possible, we'd have to remove each item separately?

[goran-w]

@love-linger This new feature is nice! To keep a consistent terminology, the "Root Dir" could be named "Clone Dir" since the related settings are named "Default Clone Dir"? (Or maybe the settings should be named "Default Root Dir" instead?)

Additionally, I think it would now make sense here to (optionally) be able to scan ANY directory (by folder-selector) without having to re-visit the settings dialog?

[goran-w]

BTW, I could live with a single "global" shared repositories-list on the Welcome page/tab, if only the following quality-of-life features were implemented:

• Add a quick way to clear the WHOLE list (for starting fresh) EDIT: This could be solved by the next point...
• Allow multi-selection ability in the list, with at least part of the context-menu retained for multi-selection (Move to Another Group, Delete).
• (Make drag-drop work on multi-selection - but this is not crucial.)
• Make it possible to drag-drop item(s) from inside a group into ROOT (or any other Group), by dropping them (anywhere) onto other non-group items in ROOT (or in another Group). In other words: allow dropping item(s) onto a non-Group item, by moving the dropped item(s) into the Parent-Group of the (non-Group) drop-target item. Implemented in PR Allow drag-drop of item (or folder) anywhere in repo-list #1459.

Also, the Search Repositories... filter currently displays ALL sub-items (even recursively) of a filter-matching Group. Instead, it should display only filter-matching items (and, by necessity, their hierarchy of containing parent-Groups). In this example, only the items with 'test' in their names (and their "ancestor"-Groups) should be visible in the filtered hierarchy: (EDIT - Not an issue...)

(Side note: I still come to a slight halt before choosing "Delete" on a repo in this list - I think a better name would be "Remove", since the repo/clone is only removed from the list, not deleted from disk...) 😅

[love-linger]

Regarding the Search Repositories... feature, there are no plans to modify it. For example, since we provide the Open All Repositories context menu entry of selected group, I usually suggest my friends to use it in conjunction with Workspace. That is, each group corresponds to one Workspace. If we only want to display the repositories managed by a certain Workspace here, we just need to filter by the Workspace name.

Take myself as another example

Group	Workspace	Description
Github	- (no workspace, shared between workspaces instead)	Repositories(cloned from GitHub) belong to others
Mine	Mine	Repositories belong to myself
Work	Work	My work repositories

[goran-w]

If we only want to display the repositories managed by a certain Workspace here, we just need to filter by the Workspace name.

Huh? Why would you even need to use a filter for that, then, when you can just expand the relevant group?

That's a rather confusing and unintuitive way to implement a search/filter - to work as one would expect, the filter instead needs to be more consistent with how filtering works in the Local Changes and Files views.

In my example screenshot, I expected to see only the (filter-matching) test_b item under the test Group, and not all the other (unmatched) items under that Group.

We should be able to filter items consistently, even when the filter string happens to coincide with a part of a Group name. For example: if I start typing est to locate an item named estimate among lots of items under a Group named test, I expect the search result to narrow down instead of showing all the (unmatched) items under the Group still...