Repository navigation
Generic Git URL configs keep percent-encoded repo names #1384
Description
Activity
can you elaborate why this is a issue?
I'd like to pick this up. Root cause confirmed:
compileGenericGitHostConfig_urlinpackages/backend/src/repoCompileUtils.tsderives the repo name fromremoteUrl.pathnamewithout decoding, while the file-based path (compileGenericGitHostConfig_file) already callsdecodeURIComponent. So a direct URL like.../Project%20Name%20With%20Spaces.gitkeeps%20inname/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.@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 aszoekt.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:
#1389What the PR does:
- adds a small shared
decodePathnamehelper - 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:
- valid encoded path:
Project%20Name%20With%20Spaces.gitbecomesProject Name With Spaces - malformed encoded path:
Project%GGName.gitis 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 buildSo 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.
I would like to take this on. The direct-URL path in compileGenericGitHostConfig_url builds the repo name from the raw percent-encoded pathname, while the file-based path already decodes it. I will put up a small PR reusing the same decodeURIComponent approach.
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 likegithub.com/test/Project%20Nameinstead of the decoded repo name.Reproduction
Configure a generic Git URL such as
https://github.com/test/Project%20Name%20With%20Spaces.gitand 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
%20inname,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.