Repo flag ignores local repo for login detection #191

New Issue

check if argument is path
-> yes: expect it is a git repo and use it's remotes to get correct login and repo path
-> no: use default login (or -l login) and argument is path to repo

B. case --repo not set:

if $PWD is git repo:
-> yes: use it's remotes to get login and repo path
-> no: if only login is needed use default or fail

in any case if -l is set overide detected/not detected login and use specified one

how login detection should work: A. case `--repo` set: 1. check if argument is path 2. -> yes: expect it is a git repo and use it's remotes to get correct login and repo path 3. -> no: use default login (or -l login) and argument is path to repo B. case `--repo` not set: 1. if $PWD is git repo: 2. -> yes: use it's remotes to get login and repo path 3. -> no: if only login is needed use default or fail in any case if `-l` is set overide detected/not detected login and use specified one

6543 commented

2020-09-21 04:36:05 +00:00

@noerw so you like to change behaviour of case A.3 ?

to still determine login if $PWD is inside git repo

-> at this point we should ad a smal flow chart documentation how login & repo path is determinated

PS: A.3 also use current loged in user as owner if no owner was set ...

@noerw so you like to change behaviour of case A.3 ? to still determine login if $PWD is inside git repo -> at this point we should ad a smal flow chart documentation how login & repo path is determinated PS: A.3 also use current loged in user as owner if no owner was set ...

noerw added the

kind/bug

label 2020-09-30 07:00:00 +00:00

6543 added this to the v0.6.0 milestone 2020-09-30 08:39:14 +00:00

noerw commented

2020-12-08 21:09:50 +00:00

@6543 yes i want case A.3 to be

1. check if argument is file path
3. -> no: get login from PWD repo if available  (or -l login or default),
          repo argument is interpreted as override to gitea repo slug (owner/repo)

But IMO we should drop support for either A.2 or A.3.:
With this overload, --repo is very confusing (and I didn't even know that it supports file paths... ?)

Looking at usecases to help deciding if we can drop support for one case:

--repo path/to/local/repo:
1. Doing quick operations on repos without changing PWD
2. ...?
--repo gitea/tea
1. operating on a different repo (i.e. fork), with context (login) from the repo in PWD: tea issues --repo noerw/tea

1.i. is just sugar for cd path/to/local/repo; tea ...`, while 2.i enables use cases that wouldn't be possible without it.

@6543 yes i want case A.3 to be ``` 1. check if argument is file path 3. -> no: get login from PWD repo if available (or -l login or default), repo argument is interpreted as override to gitea repo slug (owner/repo) ``` But IMO we should drop support for either A.2 or A.3.: With this overload, `--repo` is very confusing (and I didn't even know that it supports file paths... ?) Looking at usecases to help deciding if we can drop support for one case: 1. `--repo path/to/local/repo`: 1. Doing quick operations on repos without changing PWD 2. ...? 2. `--repo gitea/tea` 1. operating on a different repo (i.e. fork), with context (login) from the repo in PWD: `tea issues --repo noerw/tea` 1.i. is just sugar for `cd path/to/local/repo`; tea ...`, while 2.i enables use cases that wouldn't be possible without it.

noerw referenced a pull request that will close this issue

2020-12-08 22:49:18 +00:00

fix InitCommand() #285

noerw added the

status/has-pull

label 2020-12-08 22:59:49 +00:00

6543 referenced this issue from a commit

2020-12-11 09:07:29 +00:00

fix InitCommand() (#285)

6543 closed this issue

2020-12-11 09:07:30 +00:00

Sign in to join this conversation.