feat: add --repo flag to issue and pull list commands #242

timstoop · 2025-10-05T00:25:33+02:00

timstoop commented

2025-10-05 00:25:33 +02:00

Add optional --repo flag to berg issue list and berg pull list
commands to allow querying repositories without being in a git
directory. The flag accepts OWNER/REPO format.

Add --repo flag to issue list (-r short option)
Add --repo flag to pull list (-R short option)
Make parse_owner_and_repo() pub(crate) for reuse
Improve error message consistency
Change ListPullRequestArgs from Copy to Clone for String field

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com

Add optional --repo flag to `berg issue list` and `berg pull list` commands to allow querying repositories without being in a git directory. The flag accepts OWNER/REPO format. - Add --repo flag to issue list (-r short option) - Add --repo flag to pull list (-R short option) - Make parse_owner_and_repo() pub(crate) for reuse - Improve error message consistency - Change ListPullRequestArgs from Copy to Clone for String field 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>

timstoop added 1 commit

2025-10-05 00:25:34 +02:00

feat: add --repo flag to issue and pull list commands 5379c20198

Add optional --repo flag to `berg issue list` and `berg pull list`
commands to allow querying repositories without being in a git
directory. The flag accepts OWNER/REPO format.

- Add --repo flag to issue list (-r short option)
- Add --repo flag to pull list (-R short option)
- Make parse_owner_and_repo() pub(crate) for reuse
- Improve error message consistency
- Change ListPullRequestArgs from Copy to Clone for String field

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

timstoop commented

2025-10-05 00:28:27 +02:00

I personally would like this feature to help with implementing an MCP correctly, but there are other reasons you may want this as well:

API/Automation use cases: Enables scripts and CI/CD pipelines to query issues/PRs from multiple repositories without needing to clone them or be in a git directory. Critical for automation tools.
Consistency with existing commands: Commands like repo info, repo clone, repo delete, and repo fork already accept OWNER/REPO arguments. This makes issue list and pull list consistent with the rest of the CLI.
Multi-repo workflows: Users managing multiple repositories can now query issues/PRs without constantly switching directories - useful for project maintainers, triage, or cross-repo searches.
Parity with gh and glab: GitHub CLI (gh) and GitLab CLI (glab) both support specifying repos via flags. Since berg positions itself as "similar to gh and glab", this brings feature parity.
Low risk, high value: Small change with no breaking behavior (flag is optional), reuses existing code patterns, well-tested approach already proven in repo commands.

I personally would like this feature to help with implementing an MCP correctly, but there are other reasons you may want this as well: * API/Automation use cases: Enables scripts and CI/CD pipelines to query issues/PRs from multiple repositories without needing to clone them or be in a git directory. Critical for automation tools. * Consistency with existing commands: Commands like repo info, repo clone, repo delete, and repo fork already accept OWNER/REPO arguments. This makes issue list and pull list consistent with the rest of the CLI. * Multi-repo workflows: Users managing multiple repositories can now query issues/PRs without constantly switching directories - useful for project maintainers, triage, or cross-repo searches. * Parity with gh and glab: GitHub CLI (gh) and GitLab CLI (glab) both support specifying repos via flags. Since berg positions itself as "similar to gh and glab", this brings feature parity. * Low risk, high value: Small change with no breaking behavior (flag is optional), reuses existing code patterns, well-tested approach already proven in repo commands.

Aviac requested changes

2025-10-06 09:01:06 +02:00

Dismissed

Aviac left a comment

Thanks for the contribution to both of you two! Just a tiny nit and we should be fine to merge this!

src/actions/repo/mod.rs Outdated

					
				@ -41,3 +41,3 @@

				/// parses a string of format OWNER/REPO

				fn parse_owner_and_repo(owner_and_repo: &str) -> anyhow::Result<(String, String)> {

				pub(crate) fn parse_owner_and_repo(owner_and_repo: &str) -> anyhow::Result<(String, String)> {

If you want to reuse this, please put it in a module own directory level above. So something like src/actions/parsing.rs. Otherwise this just entangles the submodules needlessly.

If you want to reuse this, please put it in a module own directory level above. So something like `src/actions/parsing.rs`. Otherwise this just entangles the submodules needlessly.

Done in the latest commit.

timstoop added 1 commit

2025-10-06 09:26:17 +02:00

refactor: move parse_owner_and_repo to dedicated parsing module 2d621c4af3

Move parse_owner_and_repo function from src/actions/repo/mod.rs to
src/actions/parsing.rs to avoid entangling submodules, as suggested
in upstream review feedback.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

timstoop added 1 commit

2025-10-06 09:27:54 +02:00

Merge branch 'main' of ssh://codeberg.org/Aviac/codeberg-cli into feature/repo-flag-issues-pulls ae83f34834

Resolve merge conflicts after upstream renamed GeneralArgs to GlobalArgs
and integrate parsing module changes.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Aviac approved these changes

2025-10-06 09:29:03 +02:00

Aviac merged commit 896fd59ba9 into main

2025-10-06 15:44:03 +02:00

Aviac referenced this pull request from a commit

2025-10-06 15:44:05 +02:00

feat: add --repo flag to issue and pull list commands (#242)

timstoop referenced this pull request from a commit

2025-10-06 16:51:02 +02:00

feat: add --repo flag to issue and pull list commands (#242)

Sign in to join this conversation.

No reviewers