You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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
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
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):
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.
The text was updated successfully, but these errors were encountered: