feat: Resolve issues and PRs by full GitHub URL

[charlesvien]

Problem

Pasting a full GitHub issue or PR URL into the message editor's issue picker fell through to a title-only text search and returned "No issues or pull requests found."

Changes

1. Add parseGithubRefUrl covering both /issues/N and /pull/N
2. Short-circuit searchGithubRefs to a direct gh view on URL match
3. Resolve against the URL's repo so cross-repo references work
4. Read pathname rather than full_name (git-url-parse drops the issue suffix)
5. Add parser tests for issue and PR URL shapes

How did you test this?

Manually

Publish to changelog?

[charlesvien]

• feat: Resolve issues and PRs by full GitHub URL #2094 👈 (View in Graphite)
• feat: Track individual subscription start and cancel events #2079
• fix: Handle SSH over HTTPS GitHub remote URLs #2049
• feat: Polish onboarding, tour and branch checkout flows #2047
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Comments Outside Diff (1)

1. packages/git/src/utils.ts, line 163-179 (link)

   parsePrUrl is now a subset of parseGithubRefUrl — both functions duplicate the same gitUrlParse call, github.com source check, and number validation. Per the OnceAndOnlyOnce rule, parsePrUrl could become a thin wrapper: const ref = parseGithubRefUrl(url); if (!ref || ref.kind !== 'pr') return null; return { owner: ref.owner, repo: ref.repo, number: ref.number };. This would also bring parsePrUrl onto the pathname-based parsing path as a bonus fix.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/git/src/utils.ts
   Line: 163-179
   
   Comment:
   `parsePrUrl` is now a subset of `parseGithubRefUrl` — both functions duplicate the same `gitUrlParse` call, `github.com` source check, and number validation. Per the OnceAndOnlyOnce rule, `parsePrUrl` could become a thin wrapper: `const ref = parseGithubRefUrl(url); if (!ref || ref.kind !== 'pr') return null; return { owner: ref.owner, repo: ref.repo, number: ref.number };`. This would also bring `parsePrUrl` onto the `pathname`-based parsing path as a bonus fix.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/main/services/git/service.ts:1555-1565
The ternary `urlRef.kind === "pr" ? "pr" : "issue"` is superfluous — `urlRef.kind` is already typed as `"issue" | "pr"`, and both string values map directly to the `gh` CLI sub-command. The ternary says the same thing twice (violating the OnceAndOnlyOnce rule).

```suggestion
      return this.fetchGhRefs(
        [
          urlRef.kind,
          "view",
          String(urlRef.number),
          "--repo",
          repoSlug,
        ],
        repoSlug,
        urlRef.kind,
      );
```

### Issue 2 of 2
packages/git/src/utils.ts:163-179
`parsePrUrl` is now a subset of `parseGithubRefUrl` — both functions duplicate the same `gitUrlParse` call, `github.com` source check, and number validation. Per the OnceAndOnlyOnce rule, `parsePrUrl` could become a thin wrapper: `const ref = parseGithubRefUrl(url); if (!ref || ref.kind !== 'pr') return null; return { owner: ref.owner, repo: ref.repo, number: ref.number };`. This would also bring `parsePrUrl` onto the `pathname`-based parsing path as a bonus fix.

_{Reviews (1): Last reviewed commit: "Resolve issues and PRs by full GitHub UR..." | Re-trigger Greptile}

[arthurdedeus]

lgtm!

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/git/src/utils.test.ts:237-252
**Asymmetric negative coverage for `pull` rejects**

The `pr` rejects block is missing test cases for `pull/-1` and `pull/42.5` that are explicitly covered in the `issue` rejects block. The implementation shares the same validation path so the behaviour is correct, but the test asymmetry means a future refactor could silently regress negative-number or fractional-number rejection for PR URLs without a test catching it.

_{Reviews (2): Last reviewed commit: "unify github url parsing into one functi..." | Re-trigger Greptile}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/git/src/utils.test.ts:250-252
The rejects block tests `issues/-1` and `issues/42.5` but is missing the equivalent `pull/-1` and `pull/42.5` cases, leaving the two invalid-number paths asymmetrically covered. Since the code uses the same `Number(num)` / `Number.isInteger` guard for both segments, these are easy to add to the existing `it.each`.

```suggestion
      "https://github.com/PostHog/code/pull/abc",
      "https://github.com/PostHog/code/pull/0",
      "https://github.com/PostHog/code/pull/-1",
      "https://github.com/PostHog/code/pull/42.5",
      "https://github.com/PostHog/code/pull/",
```

_{Reviews (3): Last reviewed commit: "drop redundant ternary on urlRef.kind" | Re-trigger Greptile}

[greptile-apps]

_{Reviews (4): Last reviewed commit: "cover pull/-1 and pull/42.5 in url tests" | Re-trigger Greptile}

[greptile-apps]

_{Reviews (5): Last reviewed commit: "cover pull/-1 and pull/42.5 in url tests" | Re-trigger Greptile}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/git/src/utils.test.ts:122-136
**Missing rejection cases dropped from old test suite**

Two explicit rejection cases from the old `parseGitHubUrl` test — `"github.com/PostHog/code"` (no protocol) and `"//github.com/PostHog/code"` — were removed without being added to any positive group. If `git-url-parse` now parses them as valid GitHub URLs under the `resource`-based check, they should appear in the `repo` positives; if they still return `null`, they should remain in `rejects`. Either way, leaving them untested hides a behavioral change in the parsing contract.

_{Reviews (6): Last reviewed commit: "cover pull/-1 and pull/42.5 in url tests" | Re-trigger Greptile}

[greptile-apps]

_{Reviews (7): Last reviewed commit: "cover pull/-1 and pull/42.5 in url tests" | Re-trigger Greptile}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/git/src/utils.test.ts:204-230
**Missing reject coverage for no-protocol URL forms**

`"github.com/PostHog/code"` and `"//github.com/PostHog/code"` were explicitly tested as null-returning in the old `parseGitHubUrl` reject list but are absent from the new `rejects` block. It's unclear whether the new implementation still rejects them (likely, since `resource` would not match for the no-protocol form) or now silently accepts them. Adding both back to the `rejects` table would confirm the intended boundary.

_{Reviews (8): Last reviewed commit: "cover pull/-1 and pull/42.5 in url tests" | Re-trigger Greptile}

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Try greploops.