drop features to improve usability #379

New Issue

noerw · 2021-07-08T20:38:53Z

noerw commented

2021-07-08 20:38:53 +00:00

I have the impression that usability of tea is rather low, as it tries to accomodate far too many different workflows for the same tasks (and lacks documentation for assumptions).
The flags needed for this create confusion as they target the same entities in different ways.

To simplify things, I propose to

Simplify the --repo flag.
It currently allows specifying remote repos via owner/repo slugs, and local repos via a local directory path. #378 is a problem that results from this.
→ remove ability to specify local paths. If you need context of a local repo, just cd to it first.

If dropping that usecase seems like a bad idea (please report!), an alternative would be to decouple both concepts and have a separate --local-repo flag for this.
Remove --remote flag.
This flag can be used to specify a different remote in the local repo to detect a different remote repo than the default (which is derived from the local master branch).
I personally never used it, and talking to users (N=4) this seems to create quite some confusion.
If you need to specify a different remote repo, just use the --repo flag explicitly
Simplify specifying remote repos for tea pr create. Currently, overriding the base repo is done via the --repo flag, but overriding the head repo is done by using an arcane head branch specifier --head <username>:<branch>.

I don't know which syntax to settle on, but mixing these seems bad.
Document assumptions about workflows with tea. i.e. things like
- tea works best in a upstream/fork workflow, when the main branch tracks the upstream repo
- ...
drop SSH support entirely, we can authenticate everything with the access token we store already (only a user facing change with regard to login-setup).

If you have thoughts about further simplification of the CLI, write them up here! ;)

I have the impression that usability of tea is rather low, as it tries to accomodate far too many different workflows for the same tasks (and lacks documentation for assumptions). The flags needed for this create confusion as they target the same entities in different ways. To simplify things, I propose to 1. Simplify the `--repo` flag. It currently allows specifying *remote* repos via `owner/repo` slugs, and *local* repos via a local directory path. https://gitea.com/gitea/tea/issues/378 is a problem that results from this. → **remove ability to specify local paths**. If you need context of a local repo, just `cd` to it first. If dropping that usecase seems like a bad idea (please report!), an alternative would be to decouple both concepts and have a separate `--local-repo` flag for this. 2. Remove `--remote` flag. This flag can be used to specify a different remote in the local repo to detect a different remote repo than the default (which is derived from the local master branch). I personally never used it, and talking to users (N=4) this seems to create quite some confusion. If you need to specify a different remote repo, just use the `--repo` flag explicitly 3. Simplify specifying remote repos for `tea pr create`. Currently, overriding the base repo is done via the `--repo` flag, but overriding the head repo is done by using an arcane head branch specifier `--head <username>:<branch>`. I don't know which syntax to settle on, but mixing these seems bad. 4. Document assumptions about workflows with tea. i.e. things like - tea works best in a upstream/fork workflow, when the main branch tracks the upstream repo - ... 5. drop SSH support entirely, we can authenticate everything with the access token we store already (only a user facing change with regard to login-setup). --- If you have thoughts about further simplification of the CLI, write them up here! ;)

noerw added the

kind/proposal

label 2021-07-08 20:38:53 +00:00

noerw changed title from ~~Simplify flags~~ to drop features to improve usability

2021-07-08 20:39:20 +00:00

noerw referenced this issue

2021-07-08 20:59:53 +00:00

difficulty creating PR #377

noerw referenced this issue

2021-09-04 13:32:59 +00:00

Drop features to reduce friction on first use #395

noerw added the