Add a bunch of aliases to align with gh

[untitaker]

• Fix Aligning with GitHub CLI? #86
• Add a few more command aliases (ls/list, new/create)
• Add --web flag to open in browser
• Add --force flag to upsert labels

Those were all things that I either 1) depend on in my wrapper scripts in my dotfiles 2) extracted from failed tool calls in my claude history.

Let me know if you want me to split that up, but I think the changes are simple enough and splitting them up, then merging them back together causes merge conflicts.

[andrew]

Thanks for this, the gh-compat direction is very welcome. A few things before merging:

Blocking

--web URLs are GitHub-only (internal/cli/pr.go, internal/cli/issue.go)

pr view --web builds https://{domain}/{owner}/{repo}/pull/{N}. That path is wrong for every non-GitHub forge we support: Gitea/Forgejo use /pulls/{N}, GitLab uses /-/merge_requests/{N}, Bitbucket uses /pull-requests/{N}.

The fix is right there though: three lines below, the code already fetches the PR, which has pr.HTMLURL populated by each backend. Move the flagWeb check after the Get() call and open pr.HTMLURL instead. Same for issue view --web with issue.HTMLURL.

pr list --web and label list --web have the same problem but no object to read from. browse.go already hardcodes /pulls so this is at least consistent with an existing bug; happy to accept it for now and push URL construction into the Forge interface in a follow-up.

Should fix

--labels alias registration

Binding a second StringSliceVar to the same &flagLabels has two side effects:

• Both --label and --labels show in --help with identical descriptions
• --label foo --labels bar yields ["bar"], not ["foo","bar"], because each pflag slice value tracks its own changed bit and resets on first Set

Cleaner would be a SetNormalizeFunc that rewrites labels to label, or at minimum cmd.Flags().MarkHidden("labels") after registering it.

Notes (no change needed)

• repoFromFlag now rejects 4+ segments. GitLab subgroups (gitlab.com/group/sub/project) hit this, but the old LastIndex code parsed them wrong anyway and gh itself only does 3 parts, so not a regression. The explicit error is an improvement.
• isLabelExistsError string-matching is brittle (a forge with different wording falls through) but there's no typed error to check and the failure mode is just "didn't upsert", so acceptable.
• --force with neither --color nor --description sends an empty update; that's a no-op on most forges and matches gh label create --force.
• --forge-type is silently ignored when --repo includes a host segment. Probably correct (explicit host wins), just flagging.

The repoFromFlag tests look good and stay hermetic since codeberg.org is in the pre-registered map.

[untitaker]

--web URLs are GitHub-only (internal/cli/pr.go, internal/cli/issue.go)

Thanks. forge browse had the same issue, so I fixed it there too. URL builder is now within each forge impl. It's a bit more than asked for but I do think it's cleaner.

Addressed the rest too.

[untitaker]

isLabelExistsError string-matching is brittle (a forge with different wording falls through) but there's no typed error to check and the failure mode is just "didn't upsert", so acceptable.

Fixed. I eyeballed the status codes for bitbucket/gitlab tbh and didn't test them, but tbf I didn't test the error message pattern matching on those forges either.

[andrew]

No problem, I appreciate the eyeballs!