Git/gitea-tea
1
0
Fork 0
mirror of https://gitea.com/gitea/tea.git synced 2026-09-15 11:28:11 +02:00
Code Issues Packages Projects Releases Wiki Activity
625 Commits 8 Branches 28 Tags
4d09587d4cb53dd3d7becee4514118993b01f7e0
Commit Graph
5 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
TylerandLunny Xiao 5fa24b9a65 feat(pulls): add --draft to create and --draft/--ready to edit (#1008) 
Closes #979. An alternative to the approach in #980 — this one is purely client-side title-mangling, no SDK changes needed.

Gitea already treats any PR with a `WIP:` or `[WIP]` title prefix (case-insensitive) as a draft. This patch wires three flags around that behavior:

- `tea pulls create --draft` — prepend `WIP: ` to the title at creation time
- `tea pulls edit --draft <idx>` — add `WIP: ` to an existing PR's title
- `tea pulls edit --ready <idx>` — strip any recognized draft prefix

All three are idempotent. `--draft` and `--ready` on edit are mutually exclusive. If the user also passes `--title` on edit, the toggle applies to the supplied title; otherwise the current title is fetched from the server first.

Why this approach over a server-payload-based one: Gitea's draft state is *defined* as the title-prefix convention (see the Gitea source for `HasWIPPrefix`). Modeling it server-side would either duplicate or fight that. A small string helper covers it without needing the SDK to add a `Draft` field.

Verified against `gitea.com` (1.26.0+dev) with a throwaway repo:
- create with `--draft` → server reports `draft: true` ✓
- `edit --ready` strips → `draft: false` ✓
- `edit --draft` adds back → `draft: true` ✓
- second `edit --draft` is idempotent ✓
- `edit --draft --ready` errors ✓

Unit tests for the prefix detection live in `modules/utils/draft_test.go`.

---

This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step. Reproduction, design decisions, and the choice not to follow #980's payload approach were mine — happy to discuss any of it.

*pull request created by Tyler's lovingly wrangled demon machine <3*

---------

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1008
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
 2026-05-31 02:50:32 +00:00
TylerandLunny Xiao 18274f1ebc fix(pulls): restore standard fork-flow PR creation (#1010) 
Closes #1009.

## The standard fork-flow

The textbook workflow for opening a PR with any git CLI (gh, glab, hub, tea, etc.) is:

1. Fork `upstream/repo` on the server.
2. Clone the fork locally; add `upstream` as a second remote.
3. Branch off, commit, push the branch to your fork.
4. Tell the tool: "open a PR on `upstream/repo`, source is `fork:branch`".

In tea that's:

```
tea pulls create --repo upstream/repo --head fork:branch --base main
```

This is the flow tea supported before #850 and the flow this repo's own contribution model assumes.

## What broke

#850 ("Enable git worktree support and improve pr create error handling", Nov 2025) correctly addressed worktree detection by adding `LocalRepo: true` to `runPullsCreate`'s `CtxRequirement`. But that requirement is checked before `--repo` is interpreted, and a slug-style `--repo gitea/tea` doesn't satisfy `LocalRepo` — only a path does.

Result: the standard fork-flow invocation above started failing with:

```
Error: local repository required: execute from a repo dir, or specify a path with --repo
```

— which is misleading, because the user IS in a repo dir and `--repo` IS set.

## The fix

Only require `LocalRepo` when the command genuinely needs the working tree:

- **Interactive mode** (no flags) — uses tree info for prompts.
- **`--head` omitted** — defaults head from the current branch.

Otherwise the command runs with just `RemoteRepo`, and `task.CreatePull` takes the explicit `--repo` and `--head` as given. The #850 worktree fix is preserved for the in-tree path.

## Behavior table

| Invocation | Before | After |
|---|---|---|
| `tea pulls create` (interactive) | works | works (unchanged) |
| `tea pulls create --head my-branch --base main` (in-tree, same repo) | works | works (unchanged) |
| `tea pulls create --repo upstream/repo --head fork:branch --base main` (fork-flow) | **fails with misleading error** | **works** |
| `tea pulls create --repo upstream/repo --base main` (no `--head`, no working tree) | fails | still fails with the same error (correctly — head can't be defaulted without a working tree or explicit flag) |

## Verification

Smoke-tested by opening a PR from `/tmp` (deliberately not a git repo):

```
cd /tmp
tea-dev pulls create --login gitea.com --repo dinsmoor/tea-testing \
                     --head dinsmoor:xfork-smoke --base main \
                     --title "xfork smoke test" --description "..."
→ https://gitea.com/dinsmoor/tea-testing/pulls/4
```

And in fact, **this very PR was opened using the patched binary** invoked from `/tmp`, since the released `tea` still has the bug.

---

This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.

*pull request created by Tyler's lovingly wrangled demon machine <3*

---------

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1010
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
 2026-05-28 18:29:11 +00:00
TylerandLunny Xiao d1b9b7735e fix(comment): don't block on stdin when body is given positionally (#1011) 
## The bug

`tea comment <idx> "body"` hangs forever in any non-TTY context — CI pipelines, subshells, agent harnesses, scripts — unless the user explicitly redirects stdin with `< /dev/null`.

### Reproduction (released `tea` 0.14.1)

```
# Plain positional body — hangs forever
$ tea comment --repo owner/repo 1 "body text"

# Heredoc body — hangs forever
$ tea comment --repo owner/repo 1 "$(cat <<'EOM'
body text
EOM
)"

# Workaround that works (but shouldn't be necessary)
$ tea comment --repo owner/repo 1 "body text" < /dev/null
```

Verified on `gitea.com` (server 1.26.0+dev) with `tea 0.14.1`. Both hanging cases hit a 30s timeout in testing; in normal shell use they hang indefinitely.

## Root cause

`cmd/comment.go:58-65`:

```go
body := strings.Join(ctx.Args().Tail(), " ")
if interact.IsStdinPiped() {
    if bodyStdin, err := io.ReadAll(ctx.Reader); err != nil {
        return err
    } else if len(bodyStdin) != 0 {
        body = strings.Join([]string{body, string(bodyStdin)}, "\n\n")
    }
}
```

`interact.IsStdinPiped()` is implemented as `!term.IsTerminal(os.Stdin)` — true for *any* non-TTY stdin, not just for piped data. When tea enters this branch in a subshell where stdin is open but no producer ever writes to it (the typical case for shell scripts and automation), `io.ReadAll` blocks waiting for an EOF that never arrives.

## Fix

Only consume stdin when the user did **not** supply a positional body. If they passed a body via args, that's their content — ignore stdin entirely.

```go
if len(body) == 0 && interact.IsStdinPiped() {
    // ... read stdin ...
    body = string(bodyStdin)
}
```

## Behavior matrix

| Invocation | Before | After |
|---|---|---|
| `tea comment <idx> "body"` (TTY) | works | works |
| `tea comment <idx> "body"` (non-TTY, no redirect) | **hangs forever** | **works** |
| `tea comment <idx> "body" < /dev/null` | works | works |
| `echo body \| tea comment <idx>` | works | works |
| `tea comment <idx> "prefix"` + piped stdin | "prefix" + stdin concatenated | positional body wins, stdin ignored |
| `tea comment <idx>` (TTY, no body, no pipe) | opens editor | opens editor |

The one behavior change is the prefix-plus-stdin case (5th row). I couldn't find anyone relying on that pattern and it wasn't documented; defaulting to "positional body wins" matches the principle of least surprise.

## Verification

Confirmed each row against `dinsmoor/tea-testing` issue #1 on `gitea.com` with the patched binary. Previously-hanging invocations now post in <0.5s. Piped-stdin path unchanged.

---

This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.

*pull request created by Tyler's lovingly wrangled demon machine <3*

---------

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1011
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
 2026-05-28 17:45:44 +00:00
TylerandLunny Xiao 6dd33b5f4f docs(login): make the git credential helper discoverable (#1014) 
Closes #1013.

## Background

While trying to use `tea` from a non-interactive context I hit a friction point: after `tea login add` succeeded, plain `git push` over HTTPS still prompted for credentials. I filed #1013 as a feature request to add credential helper integration — then found, on reading the source, that the integration **already exists**:

- `tea login add` accepts `--helper` (alias `-j`), which calls `task.SetupHelper` to register a credential helper in `~/.gitconfig`.
- `tea login helper get` correctly implements git's credential protocol, reading the request from stdin and returning `protocol`/`host`/`username`/`password` lines.
- `tea login helper setup` does the same for every configured login.

I verified end-to-end that this works as advertised: after `tea login helper setup`, an HTTPS `git push` against a configured Gitea host authenticates silently using the stored token, no prompts, with `GIT_TERMINAL_PROMPT=0` set as a safety check.

So the feature is fine. The problem is that nobody can find it:

| Surface | Before | Issue |
|---|---|---|
| Flag name on `tea login add` | `--helper` (alias `-j`) | Generic; nothing tying it to git or credentials |
| Flag usage text | `"Add helper"` | Says nothing |
| `tea login helper` command | `Hidden: true` | Not in `tea login --help` |
| `tea login helper` usage | `"Git helper"` | Says nothing |
| `tea login helper` description | `"Git helper"` | Same string again |
| `store/erase` subcommand description | `"Command drops"` | Sentence fragment, no meaning |
| `setup` subcommand description | `"Setup helper to tea authenticate"` | Awkward, doesn't explain what it touches |
| `get` subcommand description | `"Get token to auth"` | Doesn't mention git, stdin, or the credential protocol |
| Mention in `tea login add --help` | None | Feature is invisible |

## What this patch does

Purely cosmetic / documentation changes — **no behavior changes**:

1. Renames `--helper` to `--git-credentials`, keeping `--helper` and `-j` as aliases so existing scripts and muscle memory keep working.
2. Removes `Hidden: true` from `tea login helper` so it appears in `tea login --help`.
3. Rewrites every placeholder `Usage` and `Description` string in the helper command tree to describe what the thing actually does.
4. Expands the top-level `Description` of `tea login add` to mention the option and explain what it does.
5. Prints a one-line hint after a successful non-helper login: `Tip: pass --git-credentials (or run 'tea login helper setup') to authenticate 'git push' and 'git clone' over HTTPS with this token.`

The credential helper protocol implementation, `SetupHelper`'s gitconfig writes, and the `get`/`store`/`setup` action functions are all unchanged.

## Help output after the patch

```
$ tea login --help
COMMANDS:
   ...
   helper, git-credential  Act as a git credential helper for stored Gitea logins
   ...

$ tea login helper --help
NAME:
   tea logins helper - Act as a git credential helper for stored Gitea logins

DESCRIPTION:
   Speaks git's credential helper protocol so that HTTPS push and clone
   operations against your configured Gitea instances authenticate silently
   using the tokens tea already stores.

   Typical use is automatic: 'tea login add --git-credentials' (or 'tea login
   helper setup' for existing logins) registers '!tea login helper' as a
   credential helper in ~/.gitconfig. Git then invokes the 'get' subcommand
   when it needs credentials for a configured host.

COMMANDS:
   store, erase  No-op (git credential protocol store/erase)
   setup         Register tea as a git credential helper for every configured login
   get           Return the stored token for a URL (git credential protocol)
```

## Open questions for the reviewer

A few choices in here that are subjective — happy to change any of them:

- **Flag name**: `--git-credentials` was the first clear name I tried. `--credential-helper` and `--git-helper` are also reasonable. Or keep `--helper` as canonical and just fix its usage text.
- **Canonical subcommand name**: I kept `helper` as canonical with `git-credential` as alias, matching what was already there. Could flip this — `gh` uses `gh auth git-credential` as canonical with no `helper` form.
- **Should `--git-credentials` default to true?** Most users probably want it on; the current opt-in design surprises them. But flipping the default is a behavior change so I left it alone here.
- **Should the hint be silenced by an env var or a config flag?** I left it always-on for the people who need to see it; can gate it if it bothers automation users.
- **Teardown on `tea login delete`** would parallel the setup behavior, but is genuinely a separate change. Not in this PR.

---

This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.

*pull request created by Tyler's lovingly wrangled demon machine <3*

---------

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1014
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
 2026-05-28 17:38:58 +00:00
TylerandLunny Xiao 23a3967e15 fix(print): distinguish draft PRs from conflicting PRs (#1012) 
## The bug

`tea pulls create` and `tea pulls edit` print `• **Conflicting files**` for any open PR that the server reports as `mergeable: false`. But Gitea's API returns `mergeable: false` for **draft PRs by design** — drafts cannot be merged regardless of conflict state. The current code conflates "not mergeable for any reason" with "has file conflicts."

### Reproduction (gitea.com 1.26.0+dev)

```
$ tea pulls create --base main --head my-branch --title "WIP: clean diff" --description "..."
  # #N WIP: clean diff (open)
  ...
  • **Conflicting files**           ← misleading
  • Maintainers are allowed to edit
```

The PR has no actual conflicts. The web UI shows it as draft + cleanly diffable. `tea pulls edit --title "WIP: ..."` shows the same misleading line.

API confirms the root signal:

```
$ curl /api/v1/repos/owner/repo/pulls/N
{ "draft": true, "mergeable": false, ... }
```

Strip the WIP prefix, and `mergeable` flips back to `true`. So `mergeable=false` here means "blocked because draft," not "conflicts."

## Fix

Distinguish the two reasons in `modules/print/pull.go`:

```go
switch {
case pr.Mergeable:
    out += "- No Conflicts\n"
case pr.Draft:
    out += "- Draft (not mergeable until marked ready)\n"
default:
    out += "- **Conflicting files**\n"
}
```

Real conflicts still fall through to the existing "Conflicting files" message.

## Behavior matrix

| PR state | API `mergeable` | Before | After |
|---|---|---|---|
| Open, clean, ready | true | No Conflicts | No Conflicts |
| Open, draft, clean | false | **Conflicting files** (wrong) | **Draft (not mergeable until marked ready)** |
| Open, conflicting | false | Conflicting files | Conflicting files |
| Closed/merged | — | (no line shown) | (no line shown) |

## Verification

Against `dinsmoor/tea-testing` PR #6 on gitea.com:

- Set title to `WIP: ...` → API `mergeable=false`, `draft=true` → tea prints `Draft (not mergeable until marked ready)` ✓
- Strip WIP → API `mergeable=true`, `draft=false` → tea prints `No Conflicts` ✓

---

This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.

*pull request created by Tyler's lovingly wrangled demon machine <3*

Reviewed-on: https://gitea.com/gitea/tea/pulls/1012
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
 2026-05-28 17:29:00 +00:00