Generic Git URL configs keep percent-encoded repo names

[DivyamTalwar]

Problem

Generic Git connection configs that point directly at an HTTP(S) remote derive repo names from the raw URL pathname. If the remote path contains encoded characters, such as %20, Sourcebot stores names like github.com/test/Project%20Name instead of the decoded repo name.

Reproduction

Configure a generic Git URL such as https://github.com/test/Project%20Name%20With%20Spaces.git and compile the connection config.

Expected

The direct URL path should match the existing file-based generic Git behavior and derive github.com/test/Project Name With Spaces.

Actual

The direct URL path keeps %20 in name, displayName, and zoekt metadata.

Impact

The same remote can produce inconsistent Sourcebot/zoekt repo identifiers depending on whether it is configured as a direct URL or discovered from a local repository origin.

[brendan-kellam]

can you elaborate why this is a issue?

[rachit367]

I'd like to pick this up. Root cause confirmed: compileGenericGitHostConfig_url in packages/backend/src/repoCompileUtils.ts derives the repo name from remoteUrl.pathname without decoding, while the file-based path (compileGenericGitHostConfig_file) already calls decodeURIComponent. So a direct URL like .../Project%20Name%20With%20Spaces.git keeps %20 in name/displayName/zoekt metadata, and the same remote gets different identifiers depending on how it's configured. To answer @brendan-kellam's question: the impact is inconsistent repo identifiers for the same remote across the URL vs file-origin code paths. Fix mirrors the existing decode.

[DivyamTalwar]

@brendan-kellam absolutely, thanks for asking.

The issue is that Generic Git direct-URL configs and Generic Git file-origin configs currently derive repo identifiers differently for the same underlying remote when the URL path contains percent-encoded characters.

Concrete example:

{
  "type": "git",
  "url": "https://github.com/test/Project%20Name%20With%20Spaces.git"
}

Today, the direct URL path keeps the encoded pathname and Sourcebot derives:

github.com/test/Project%20Name%20With%20Spaces

But the file-based Generic Git path already decodes the origin URL pathname, so the same remote can become:

github.com/test/Project Name With Spaces

That matters because this derived value is not only display text. It becomes the repo name, displayName, and Zoekt metadata such as zoekt.name / zoekt.display-name. So the same repository can end up with inconsistent Sourcebot/Zoekt identifiers depending on whether it was configured directly as a Git URL or discovered from a local repository origin.

The practical impact is:

• inconsistent repo names in the UI/search metadata
• possible duplicate-looking identities for the same remote across config paths
• search/index metadata not matching the decoded repository path users expect
• Generic Git direct URL behavior not matching the existing file-origin behavior

I agree this is not a critical data-loss bug; it is more of a correctness/consistency bug in repo identity derivation.

I raised PR #1389 to fix this:
#1389

What the PR does:

• adds a small shared decodePathname helper
• uses it in the direct Generic Git URL compile path
• keeps the existing file-origin behavior aligned with the safer helper
• decodes valid URL-encoded path segments like %20
• preserves malformed percent escapes instead of throwing during config compilation

The PR includes regression coverage for both cases:

1. valid encoded path: Project%20Name%20With%20Spaces.git becomes Project Name With Spaces
2. malformed encoded path: Project%GGName.git is preserved as-is instead of causing a decode failure

Validated with:

node .yarn/releases/yarn-4.7.0.cjs workspace @sourcebot/backend test src/repoCompileUtils.test.ts
node .yarn/releases/yarn-4.7.0.cjs workspace @sourcebot/backend build

So the fix is intentionally narrow: it only normalizes Generic Git URL repo-name derivation to match the already-existing decoded behavior from the file-origin path, while avoiding a new failure mode for malformed encoded strings.