tea pr checkout
: fetch via ssh if available #192
No reviewers
Labels
No Label
kind/breaking
kind/bug
kind/build
kind/dependency
kind/deployment
kind/docs
kind
enhancement
kind
feature
kind/proposal
kind
question
kind
refactor
kind/security
kind/testing
kind/translation
priority/critical
priority/high
priority/low
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/has-backport
status/has-pull
status/needs-backport
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
upstream/sdk
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/tea#192
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "noerw/tea:issue-190"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
fixes #190
blocked by https://github.com/go-git/go-git/issues/173WIP: `tea pr checkout`: fetch via ssh if availableto `tea pr checkout`: fetch via ssh if availableThis one is ready now.
The upstream blocker didn't look like it will be adressed anytime soon, so I implemented a workaround:
When user has configured SSH keys in their gitea account, we will configure the remote in the local repo with the SSH URI.This only applies to new remotes, so already configured HTTPS remotes need to be deleted before running
tea pr checkout
@ -8,6 +8,7 @@ import (
"fmt"
"log"
"code.gitea.io/sdk/gitea"
import format :)
Showld we add aa config option witch decide what to use?
@6543 you mean instead of checking for SSH keys via API? I think using this check is a very good indicator of how the user wants to fetch, and is much lower friction than making them set a config option.
Now that I think about it, user may use tea on a device that has no privkey locally, while having a pubkey in gitea. In that case it would make sense to have an option to override the automatic behaviour.
@noerw I think we should add a optional conf ... and user your func by default :)
@noerw pleace update this branch :=)