Prefer origin if there are multiple remotes #458
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/tea#458
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "arkamar/tea:prefer-origin-remote"
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?
Usually,
origin
is the name of a default remote, which corresponds with upstream. This change improves remote selection when non ofmain
,master
nortrunk
local branches is present.Prefer origin if there is multiple remotesto Prefer origin if there are multiple remotesI don't think this change is correct, but I didn't find the time to verify yet (Instead I got sidetracked with https://github.com/go-gitea/gitea/pull/19030 when checking in on this yesterday ?). Will try to check this out today
After checking this out, I indeed consider this a bad change. See my reasoning in #466, where I propose a different approach
Just to advocate this PR a little bit more, I tried to do the change least invasive, therefore
main
,master
andtrunk
branches are still preferred for remote selection, butorigin
is used if non of those is present. This change does not break previous behavior, because user cannot easily predict which remote will be selected if non of previously mentioned branches is present. I don't consider it as a bad change, it really improves default behavior and user experience.Anyway, this being said, I do like the change in #466, but except of
upstream
addition nothing in remote selection priority has been changed.