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
581 Commits 8 Branches 28 Tags
6dd33b5f4fb88b1518e9907ce16e9813140dce47
Commit Graph
2 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
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