Repo flag ignores local repo for login detection #191

Closed
opened 2 years ago by noerw · 7 comments
noerw commented 2 years ago
Collaborator

#178 has reintrocuded the old bug #51:

curGitRepoPath() should be used to set login, also when repoValue is non-empty.

#178 has reintrocuded the old bug #51: `curGitRepoPath()` should be used to set `login`, also when `repoValue` is non-empty.
6543 commented 2 years ago
Collaborator

@noerw -r and -R are not the same

@noerw `-r` and `-R` are not the same
noerw commented 2 years ago
Poster
Collaborator

Yes, i know, this is about -r / --repo.

Yes, i know, this is about `-r` / `--repo`.
6543 commented 2 years ago
Collaborator

do #193 solve this issue too?!?

do #193 solve this issue too?!?
noerw commented 2 years ago
Poster
Collaborator

No this is not adressed by that PR. Sorry for the confusion with multiple bugs in one issue..

No this is not adressed by that PR. Sorry for the confusion with multiple bugs in one issue..
6543 commented 2 years ago
Collaborator

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

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 2 years ago
Collaborator

@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 2 years ago
6543 added this to the v0.6.0 milestone 2 years ago
noerw commented 2 years ago
Poster
Collaborator

@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.

@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 added the status/has-pull label 2 years ago
6543 referenced this issue from a commit 2 years ago
6543 closed this issue 2 years ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gitea/tea#191
Loading…
There is no content yet.