Skip to content

select base repo correctly when only one remote - #6803

Merged
vilmibm merged 2 commits into
trunkfrom
fix-6792
Jan 3, 2023
Merged

select base repo correctly when only one remote#6803
vilmibm merged 2 commits into
trunkfrom
fix-6792

Conversation

@vilmibm

@vilmibm vilmibm commented Jan 3, 2023

Copy link
Copy Markdown
Contributor

After a clone, gh would fail to set a base repo even if there was only one remote. this only happened if the repository cloned was not owned by the cloner.

Fixes #6792

@vilmibm
vilmibm requested a review from a team as a code owner January 3, 2023 19:59
@vilmibm
vilmibm requested review from samcoe and removed request for a team January 3, 2023 19:59
Comment thread context/context.go Outdated
Comment on lines 88 to 90
if len(repos) <= 1 && len(r.remotes) > 0 {
return r.remotes[0], nil
}

@samcoe samcoe Jan 3, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is an obscure edge case but what about a case where there are multiple remotes and they only resolve to a single repo? Returning r.remotes[0] seems like it could result in the wrong remote getting selected. What about:

// Maintain current behavior in this case.
if len(repos) == 0 {
    return r.remotes[0], nil
}

if len(repos) == 1 {
    return repos[0], nil
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not worried about it. The shape of the RepoNetwork is directly related to the list of remotes locally. Multiple remotes all resolving to a single repo is a strange enough edge-case that I don't think we have to handle it.

@samcoe samcoe Jan 3, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That one does seem unlikely. What about:

Remote 0 -> does not resolve to any GitHub repos because of auth issue or it is malformed remote or the repo was archived/deleted/renamed/etc
Remote 1 -> resolves to one GitHub repo

This is the one I was more concerned about. Normally you would think that an error would pop up and we wouldn't reach this point but the RepoNetwork query tolerates repo not found errors and so a remote can result in not resolving to any repo at all.

Going to approve the PR as the code looks good. Feel free to address this edge case if you feel it is relevant.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I see, thanks for elaborating; I wasn't interpreting your edge case correctly.

I do think there is merit in handling this after all so I'll push a commit for that.

@vilmibm
vilmibm enabled auto-merge January 3, 2023 22:00
@vilmibm
vilmibm merged commit 82156f7 into trunk Jan 3, 2023
@vilmibm
vilmibm deleted the fix-6792 branch January 3, 2023 22:10

@nitindudeja2107 nitindudeja2107 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nitindudeja2107 nitindudeja2107 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Setting default remote is required even if only one is defined

4 participants