Import: https source URLs ending in .git should be handled, not error #398

New issue

Closed

opened 2026-09-12 17:43:48 +00:00 by crueber · 1 comment

crueber commented

2026-09-12 17:43:48 +00:00

Owner

What's wrong

Importing a repo from an https:// source URL that ends in .git fails with an error, instead of being handled. The user pastes https://git.example.com/owner/repo.git (the standard git clone URL — what every forge displays in its clone box) and the import refuses, while the same URL without the suffix works.

Where the `.git` handling exists today (code evidence)

internal/repoimport/url.go — NormalizeSource:
- The GitHub paths strip the suffix properly: isGitHubShorthand/splitShorthand trim .git (:147, :169), and canonicalGitHubURL explicitly does strings.TrimSuffix(p, ".git") (:205, :211-214).
- The file header comment (:5-9) claims the generic behavior too — "anything else must be a full URL … a single stripped .git … :443/uppercase/trailing-slash/.git/ variants of one logical source" normalize to one canonical form.
But the generic (non-GitHub) https branch (:74-100) does not deliver that promise for the .git-suffixed form: the URL is carried essentially verbatim into the clone step, and the failure the user sees comes back from the import instead of being normalized away.
The mirror-create flow (POST /api/v1/repos/mirrors) rides the same NormalizeSource, so mirror imports from .git URLs fail the same way.

What's needed

Normalize the generic https path the same way the header comment already promises: a single trailing .git on the last path segment is stripped for canonicalization (so …/repo.git → …/repo), while a trailing slash form (…/repo/, …/repo.git/) is handled per the #237 normalization contract (those variants were already called out there — this ticket extends the same canonicalization to the bare .git suffix if it's not already effective on the generic path).
Verify before claiming fixed — the nuance is in which layer strips what:
- unit-test NormalizeSource directly with https://<forge>/owner/repo.git, …/repo, …/repo.git/, …/repo/ and assert one canonical form for all four;
- add an end-to-end import test (the existing repoimport test harness) proving the .git-suffixed URL actually clones and lands, not just that the normalizer returns a pretty string — the clone step consumes the canonical URL, so a normalization that doesn't survive to the clone args would pass the unit test and still fail the import.
UI courtesy: the import/mirror forms may also show the canonical URL under the source field (the canonical: hint, Import.jsx); confirm the hint shows the stripped form so the user sees the suffix was understood.

Acceptance criteria

Importing from https://<forge>/owner/repo.git succeeds identically to the same URL without the suffix (same canonical source, same provenance, same idempotent re-import/no-op behavior).
NormalizeSource unit tests cover the four variant forms above and assert a single canonical URL; the GitHub-path behavior is unchanged.
End-to-end import test proves the .git URL clones and lands (not just normalization).
The canonical-URL hint in the import/mirror forms reflects the stripped form.
The #237 canonicalization invariants hold (one logical source = one gate decision = one provenance match) for the .git variants.

## What's wrong Importing a repo from an `https://` source URL that ends in **`.git`** fails with an error, instead of being handled. The user pastes `https://git.example.com/owner/repo.git` (the standard git clone URL — what every forge displays in its clone box) and the import refuses, while the same URL without the suffix works. ## Where the `.git` handling exists today (code evidence) - `internal/repoimport/url.go` — `NormalizeSource`: - The **GitHub paths** strip the suffix properly: `isGitHubShorthand`/`splitShorthand` trim `.git` (:147, :169), and `canonicalGitHubURL` explicitly does `strings.TrimSuffix(p, ".git")` (:205, :211-214). - The file header comment (:5-9) claims the generic behavior too — "anything else must be a full URL … a single stripped `.git` … `:443`/uppercase/trailing-slash/`.git/` variants of one logical source" normalize to one canonical form. - **But the generic (non-GitHub) https branch** (:74-100) does not deliver that promise for the `.git`-suffixed form: the URL is carried essentially verbatim into the clone step, and the failure the user sees comes back from the import instead of being normalized away. - The mirror-create flow (`POST /api/v1/repos/mirrors`) rides the same `NormalizeSource`, so mirror imports from `.git` URLs fail the same way. ## What's needed 1. **Normalize the generic https path the same way the header comment already promises:** a single trailing `.git` on the *last path segment* is stripped for canonicalization (so `…/repo.git` → `…/repo`), while a trailing **slash** form (`…/repo/`, `…/repo.git/`) is handled per the #237 normalization contract (those variants were already called out there — this ticket extends the same canonicalization to the bare `.git` suffix if it's not already effective on the generic path). 2. **Verify before claiming fixed** — the nuance is in *which* layer strips what: - unit-test `NormalizeSource` directly with `https://<forge>/owner/repo.git`, `…/repo`, `…/repo.git/`, `…/repo/` and assert one canonical form for all four; - add an end-to-end import test (the existing repoimport test harness) proving the `.git`-suffixed URL actually clones and lands, not just that the normalizer returns a pretty string — the clone step consumes the canonical URL, so a normalization that doesn't survive to the clone args would pass the unit test and still fail the import. 3. **UI courtesy:** the import/mirror forms may also show the canonical URL under the source field (the `canonical:` hint, `Import.jsx`); confirm the hint shows the stripped form so the user sees the suffix was understood. ## Acceptance criteria - [ ] Importing from `https://<forge>/owner/repo.git` succeeds identically to the same URL without the suffix (same canonical source, same provenance, same idempotent re-import/no-op behavior). - [ ] `NormalizeSource` unit tests cover the four variant forms above and assert a single canonical URL; the GitHub-path behavior is unchanged. - [ ] End-to-end import test proves the `.git` URL clones and lands (not just normalization). - [ ] The canonical-URL hint in the import/mirror forms reflects the stripped form. - [ ] The #237 canonicalization invariants hold (one logical source = one gate decision = one provenance match) for the `.git` variants.

crueber added the

git storage

label

2026-09-12 17:43:48 +00:00

crueber added this to the v1 milestone

2026-09-12 17:43:48 +00:00

crueber closed this issue

2026-09-12 17:46:21 +00:00

crueber commented

2026-09-12 17:46:21 +00:00

Author

Owner

Closed: this was filed inline in violation of the Issue Writer contract (tickets go to subagents). Re-filing via subagent as # shortly - no content is lost, the same body is being refiled with the investigation evidence intact.

Closed: this was filed inline in violation of the Issue Writer contract (tickets go to subagents). Re-filing via subagent as #<new> shortly - no content is lost, the same body is being refiled with the investigation evidence intact.

crueber referenced this issue

2026-09-12 17:52:02 +00:00

Import: SPA canonical-URL hint diverges from server normalization on .git/trailing-slash/uppercase non-GitHub URLs #401

crueber referenced this issue

2026-09-12 19:10:11 +00:00

Import: SPA canonical-URL hint diverges from server normalization on .git/trailing-slash/uppercase non-GitHub URLs #401