[Bug][GitLab] Same named repositories not well handled

[themadbit]

Search before asking

• I had searched in the issues and found no similar issues.

What happened

When adding scope to the GitLab connection, if there are multiple repos with the same name, all repos are populated with the same name, and this makes it impossible to tell which exact repo I want to add to a project.

What do you expect to happen

When adding repos to the GitLab connection, if there's an already existing repo with that name, the user should be prompted to take an action. Rename the repo from their source, rename the repo as devlake, will reference it, or, when a user is choosing the repo to add, it should show the full path of the repo.

NB: This happens because GitLab has groups and subgroups that might have repos with the same name.

How to reproduce

Have to repos with the same name and add them to the GitLab Connection.
Create a project.
Add scopes to the project.
When adding the repo scopes, you'll see both named correctly
It will be difficult to tell which repo you want for this project

Anything else

No response

Version

v1.0.3-beta10@99376a8

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[dosubot]

Thanks for the detailed report. I took a look at how this is currently implemented.

The backend already provides both the short name and the full pathWithNamespace (e.g., group/subgroup/project) for every GitLab project [1]. The frontend does use the full path in two places — search results and selected tags [2] [3]:

// Search results use fullName
title: it.fullName ?? it.name

// Selected tags show fullName
<Tag key={sc.id} color="blue" closable>{sc.fullName}</Tag>

However, when browsing via the Miller Columns (the hierarchical tree view), only the short name is displayed [4]. This is likely where the confusion in your screenshot is coming from — if you have identically-named repos across different groups/subgroups, they look the same in that view.

Since the fullName data is already available from the backend, a fix would be relatively straightforward: update the Miller Columns rendering to show fullName (or at least fall back to it when duplicate names are detected). The RemoteScope type already carries both fields [5].

If anyone wants to pick this up, the relevant frontend file is the one handling the Miller Column scope selector — specifically the item rendering logic that currently uses name instead of fullName.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}