Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a possibility to guess the remote from the current branch #896

Open
glemco opened this issue Dec 18, 2024 · 0 comments · May be fixed by #897
Open

Add a possibility to guess the remote from the current branch #896

glemco opened this issue Dec 18, 2024 · 0 comments · May be fixed by #897

Comments

@glemco
Copy link

glemco commented Dec 18, 2024

The current code to guess the remote is rather smart and understands different scenarios (e.g. origin/upstream, username/origin) and falls back to using the remote of the master/main branch. This however doesn't work in a somewhat specific scenario like linux kernel development.

There exist a lot of different trees and a way to handle them is to add them as separate remote (perhaps combined with git worktree).
In this situation, I may have a repository with the upstream linux (git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git, not gitlab) as origin and another remote for centos stream (https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10).
I would then have one worktree checking out upstream and another checking out centos.
I may also have more remotes to track different centos versions or other trees, each of them having a main/master branch.

In this situation, I would like lab neither to infer the remote as origin (it isn't gitlab) nor getting it from main/master (it may not be the repository I want), but the current branch would typically track the desired remote.

A simple way for this to work is (untested):

remoteConf := fmt.Sprintf("branch.%s.remote", git.CurrentBranch())
if remote, err := gitconfig.Local(remoteConf); err == nil {
	guess = remote
}

Perhaps this could be an optionally enabled feature, if the user sets it, the branch will be selected as such first and fall back to the other method if the current branch isn't tracking a remote. If disabled, it would just not run and the behaviour would be the current one.

glemco added a commit to glemco/lab that referenced this issue Dec 18, 2024
This PR adds the configuration option `core.remote_from_branch`.
If set, the default remote is inferred from the current checked-out branch.

If unset or if `core.default_remote` is set, the behaviour is unchanged.

Fixes: zaquestion#896
@glemco glemco linked a pull request Dec 18, 2024 that will close this issue
glemco added a commit to glemco/lab that referenced this issue Dec 24, 2024
This PR adds the configuration option `core.remote_from_branch`.
If set, the default remote is inferred from the current checked-out branch.

If unset or if `core.default_remote` is set, the behaviour is unchanged.

Fixes: zaquestion#896
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 a pull request may close this issue.

1 participant