refactor: introduce project-centric data model
This MR introduces a new internal state representation. The implementation is behind feature flag which can be enabled by adding "gitlab.featureFlags": ["model-refactor"]
to the VS Code settings.json
.
With the FF enabled, we only show recognized GitLab projects in the TreeView:
The new model
The core idea behind this refactoring is:
- the local Git repository can have an arbitrary number of remote URLs
- the extension can have multiple accounts set up for the same instance. Each account might have a different view on a GitLab project (Multiple accounts are not yet supported, but they will be supported soon).
- hence we'll do a cartesian product of all remote URLs and accounts on the given GitLab instance
- Then, we'll try to fetch projects for each of these combinations and let the user decide which one they want to use
Example
Repository:
.
└── local-repository
└── origin
├── fetchUrl: git@gitlab.com:gitlab-org/gitlab
└── pushUrl: git@gitlab.com:viktomas/gitlab
Two accounts for gitlab.com
A
, and B
.
We'll end up with 4 ExistingProjects
-
gitlab-org/gitlab
fetched by userA
-
gitlab-org/gitlab
fetched by userB
-
viktomas/gitlab
fetched by userA
-
viktomas/gitlab
fetched by userB
Then we'll let the user choose out of these four, so the extension can work with a single GitLab project for local-repository
. This choice is not implemented in this MR.
It could also happen that the user B
can't access viktomas/gitlab
and then we would end up with:
-
gitlab-org/gitlab
fetched by userA
-
gitlab-org/gitlab
fetched by userB
-
viktomas/gitlab
fetched by userA
Related to #558 (closed)
Edited by Tomas Vik (OOO back on 2024-08-12)