update-with-local-changes #6
Reference in New Issue
Block a user
Delete Branch "update-with-local-changes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
## Summary Fix the `tea labels delete` and `tea labels update` commands which were silently ignoring the `--id` flag. ## Problem Both commands used `IntFlag` for the `--id` parameter but called `ctx.Int64("id")` to retrieve the value. This type mismatch caused the ID to always be read as `0`, making the commands useless. **Before (bug):** ```bash $ tea labels delete --id 36 --debug DELETE: .../labels/0 # Wrong! ID ignored ``` **After (fix):** ```bash $ tea labels delete --id 36 --debug GET: .../labels/36 # Verify exists DELETE: .../labels/36 # Correct ID Label 'my-label' (id: 36) deleted successfully ``` ## Changes ### labels/delete.go - Change `IntFlag` to `Int64Flag` to match `ctx.Int64()` usage - Make `--id` flag required - Verify label exists before attempting deletion - Provide clear error messages with label name and ID context - Print success message after deletion ### labels/update.go - Change `IntFlag` to `Int64Flag` to fix the same bug ## Test plan - [x] `go test ./...` passes - [x] `go vet ./...` passes - [x] `gofmt` check passes - [x] Manual testing confirms ID is now correctly passed to API - [ ] CI passes Reviewed-on: https://gitea.com/gitea/tea/pulls/865 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Alain Thiffault <athiffau@effectivemomentum.com> Co-committed-by: Alain Thiffault <athiffau@effectivemomentum.com>apisubcommand for arbitrary api calls not covered by existing subcommands (#879) 82d8a14c73repo editsubcommand (#928) a531faa626Implements the 'branches rename' command to rename a branch in a repository. This wraps the Gitea API endpoint PATCH /repos/{owner}/{repo}/branches/{branch}. Usage: tea branches rename <old_branch_name> <new_branch_name> Example: tea branches rename -r owner/repo main factory This resolves issue #938. Reviewed-on: https://gitea.com/gitea/tea/pulls/939 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Matěj Cepl <mcepl@cepl.eu> Co-committed-by: Matěj Cepl <mcepl@cepl.eu>## What this PR does `tea issues list --assignee USERNAME` currently returns every issue regardless of the assignee value — even nonexistent users return a full unfiltered list. Discovered against **tea v0.14.0** (with go-sdk v0.24.1) and reproduced on current `master` (commit `dd81b33`). This PR fixes that. ## Root cause Two distinct bugs on the same flag, both in `cmd/issues/list.go`: 1. **Per-repo path** (`tea issues list --repo OWNER/REPO --assignee USER`): the code reads `ctx.String("assigned-to")` for `AssignedBy`, but the flag is defined as `--assignee` in `cmd/flags/issue_pr.go:66`. The lookup always returns `""`, so the SDK omits the `assigned_by` query parameter and the API returns everything. 2. **Global path** (`tea issues list --assignee USER`, no `--repo`): this hits `/repos/issues/search`, which silently ignores `assigned_by`. Even after fix #1 the no-repo form would still return unfiltered results. Verified directly: - `GET /repos/issues/search?assigned_by=USER&owner=ORG&state=open` → all open issues - `GET /repos/issues/search?assigned=true&owner=ORG&state=open` → only the issues assigned to the authenticated user The endpoint only supports `assigned=true` (boolean self-filter), not arbitrary-user filtering, and `ListIssueOption` doesn't expose that field. Rather than misleading the caller, the no-repo path now returns a clear error. ## Changes Both changes are in `cmd/issues/list.go`: 1. Read `ctx.String("assignee")` instead of the non-existent flag name `"assigned-to"` (lines 80 and 97). 2. In the no-`--repo` branch, return `errors.New("--assignee requires --repo (...)")` when the flag is set. `cmd/pulls/list.go` does not expose an assignee filter, so it's unaffected. The `--author` mapping (`CreatedBy ← ctx.String("author")`) was already correct and is the model the fix follows. ## Manual verification Tested against a local Gitea instance with three open issues (only one assigned to the test user): | Command | Before | After | |---|---|---| | `tea issues list --repo X --assignee me` | all 3 | only the 1 assigned ✓ | | `tea issues list --repo X --assignee nonexistent` | all 3 | `Error: not found` ✓ | | `tea issues list --repo X --author me` | only the 1 (control) | unchanged ✓ | | `tea issues list --assignee me` (no `--repo`) | all 3 (silent) | clear error ✓ | | `tea issues list` (no flags) | all 3 | unchanged ✓ | --------- Co-authored-by: claude_1 <claude_1@bot.gqx.lol> Reviewed-on: https://gitea.com/gitea/tea/pulls/971 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Oleksii Zaremskyi <grossqx@gmail.com> Co-committed-by: Oleksii Zaremskyi <grossqx@gmail.com>View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.