-
Notifications
You must be signed in to change notification settings - Fork 9
Always operates on first origin #67
Comments
This is different from the assumed behavior. I will investigate the possibility of a bug. |
I made the same repository as you and tested it. However, how to handle remote of git subtree is another problem, I have to think properly. |
I tried it again and I cannot reproduce the "deleted origin" part, very strange. For the subtree, I realize it's not easy. Maybe a per-repo config for the remote to use? |
Is there some form of caching going on, because I changed the name of my remotes (prefixed with x_), so now the origin is the first one in the list of remotes, but lab still uses the original "first remote"? |
No, lab dose not use caching when referring to git remote. Always run git remote command. And if the repository has more than one remote of gitlab, we refer to the result of executing git remote from the above and target the remote found first. |
I have a repository setup with multiple subtrees. Because I added the origins of the subtrees (on gitlab) first and then pushed the new repository to gitlab, lab will operate on the first added remote instead of the real one called "origin".
Some information obfuscated for privacy reasons:
$ git remote -v build_tools git@gitlab.<hidden>/build_tools.git (fetch) build_tools git@gitlab.<hidden>/build_tools.git (push) common_libs git@gitlab.<hidden>/common_libs.git (fetch) common_libs git@gitlab.<hidden>/common_libs.git (push) origin git@gitlab.<hidden>/project.git (fetch) origin git@gitlab.<hiden>/project.git (push)
Any "lab" command will operate on the "build_tools" remote instead of the "origin" remote.
Also, if I remove the build_tools origin, lab will fail with "Not found gitlab remote repository", while there are still 2 remotes on gitlab left.
lab ver: v0.5.3 rev: 5d09e6d
git version 2.19.0
The text was updated successfully, but these errors were encountered: