Skip to content
This repository has been archived by the owner on Nov 4, 2022. It is now read-only.

Logged in user returns wrong value from git repo #648

Open
bpatram opened this issue May 28, 2019 · 5 comments
Open

Logged in user returns wrong value from git repo #648

bpatram opened this issue May 28, 2019 · 5 comments

Comments

@bpatram
Copy link
Contributor

bpatram commented May 28, 2019

gh reports my current user incorrectly when called from a folder that is a git repo (I think that's what is triggering it?).

$ gh user --whoami
First we need authorization to use GitHub's API. Login with your GitHub account.
? Enter your GitHub user bpatram
? Enter your GitHub password [hidden]
? Enter your two-factor code 851335
Writing GH config data: /Users/brandonpatram/.gh.json
Authentication succeed.
ebth

# Calling this from a repo
$ gh user --whoami
ebth

# Moving to a directory that is not a git repo
$ cd ~
$ gh user --whoami
bpatram

In my case, it seems to return the organization the repo is owned by (ebth). Interestingly enough my .gh.json does list the correct user.

    "github_user": "bpatram",

Deleting the .gh.json file and relogging has no effect.

@bpatram
Copy link
Contributor Author

bpatram commented May 28, 2019

When I remove my remotes from my local repo gh starts to report the user correctly.

$ gh user -w
ebth

$ git remote -v
origin  [email protected]:ebth/some-repo-path-here.git (fetch)
origin  [email protected]:ebth/some-repo-path-here.git (push)

$ git remote rm origin

$ git remote -v

$ gh user -w
bpatram

@bpatram
Copy link
Contributor Author

bpatram commented May 28, 2019

Some version info of gh I'm running (latest version).

├─┬ [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ └── [email protected]

@protoEvangelion
Copy link
Member

Thanks for the clear guidelines on reproducing this @bpatram. So if the origin remote has a different user, gh is giving priority to the user in the remote url?

You are right that that is a bug for the user cmd.

I know we give priority to the user in the remote url if you don't pass in --user username. Do you have thoughts on whether or not that should be the default behavior?

@bpatram
Copy link
Contributor Author

bpatram commented Jun 1, 2019

So if the origin remote has a different user, gh is giving priority to the user in the remote url?

yes, this seems to be what is happening. I tested on another repo:

# outside repo folder
$gh user --whoami
bpatram

# inside repo folder
$ gh user --whoami
brandonpatram

$ git remote -v
origin	[email protected]:brandonpatram/some-repo-path-here.git (fetch)
origin	[email protected]:brandonpatram/some-repo-path-here.git (push)

I know we give priority to the user in the remote url if you don't pass in --user username. Do you have thoughts on whether or not that should be the default behavior?

I don't think it should be. Although, I can't think of a use case where it would be preferred to use the repo's user/owner instead of the current user logged into gh. Maybe I am missing something.


To provide a bit more context into my specific use case; I use gh to build a rudimentary changelog based on a list of PR#s, I use gh user --whoami to determine if the user running the script is the author of any of those PRs.

@protoEvangelion
Copy link
Member

Here is the line that shows the logic for how the user is set. I blamed it and that line goes back to the inception of this project.

The remote origin user will win every time over the logged in user. I have never noticed that being a problem because my origin is always my username.

I am open to changing it for though for v2. I am working hard on releasing it soon but am stuck on reimplementing hooks and plugins at the moment. Nonetheless I will put it on my todos before releasing :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants