support remote names other than origin

[NikolausDemmel]

It seems like the remote name origin is hardcoded, e.g. here: https://github.com/vcstools/vcstools/blob/768f477a17e45cde8b57baed84e7661f601b73aa/src/vcstools/git.py#L155

I have checkouts where frequently the remote I want to use is not called origin. Sometimes the repo has multiple remotes (none called origin), sometimes I have one remote (not called origin).

I would suggest that wstool should dwim in those situtations, where user intent can be deduced.

E.g. a heuristic could be:

1. if there is only one remote, use that, no matter what it is called
2. if there are multiple remotes, and the local branch specified as the to-be-used version has a default remote, then use that remote
3. otherwise, if one remote is called origin, use that
4. otherwise, gracefully refuse service

[tkruse]

Supporting more remotes might be nice, but is not that trivial with wstool, because there is the .rosinstall file, and it has semantics that usually imply origin. And the general philosophy has been that if the filesystem state is strange, the tool should rather error out than try to guess what the user intended(ddwidm - don't do what I didn't mean). That's because the tool aims to support users who do not well know what they are doing.

Possibly the vcstool tool is more for you, since it does not rely on a 'workspace' file: https://github.com/dirk-thomas/vcstool
That way, the state of the folders becomes the base for all commands, and it it the full responsibility of the user to know what is going on and the consequences of launching commands.

What is unclear in your case is why you cannot use the name "origin" for your purposes. If you could explain more why the workflow needs a different name or more than one name, I might find better solutions or see more clearly how much a solution is needed.

[NikolausDemmel]

I am already using vcstool (thanks for the hint, still). The reason I just looked at wstool for my use case again is the more concise output of wstool info and wstool status. With a bunch of repos, vcs tool status is still fairly verbose and getting the info I need (which repos have changes, which repos need to be pulled / rebased / pushed) still takes some scrolling and human parsing. In particular #38 would be very useful for me.

The reason I currently have branch names != origin is the following. Since for some repos we have multiple instances, sometimes across different github (enterprise) instances, I have gotten into the habit of always properly naming my remotes, since it is not inherently clear which one should be origin. So even if I actually have only one remote configured in a checkout (maybe for that particular repo there is even only one possible remote), I choose a describing remote name for consistency and to avoid me pushing to the wrong server by accident because I made wrong assumptions about origin.

This doesn't make it impossible for to change my habbits and use origin. Most of the time, the repo I would push to is always the same one, i.e. for me there usually is a clear pick which one origin in each checkout (but it might be different remotes for different repos that I have all checked out in the same workspace). However, so far the custom remote names have helped me well and avoided accidental pushes as well as unneccessary checking of the push url of origin.

In other words, this is not a huge priority, or complete blocker, but it might mean that I will continue to use vcstool where I would actually prefer the mechanics of wstool.

I agree with the ddwidm argument, but I think the case where there is only one remote that is not named origin is really a case where a use might be surprised by the tool using that remote. As for the case where there are multple remotes and a specified branch, and that branch has one of the remotes set as the default remote: Maybe the current behaviour of always picking origin regardless is actually a ddwidm choice?

One solution could be to extend the .rosinstall format to alow specification of the remote name, but that would be a change not limited to wstool.

P.S.: If there is not origin remote, the tool currently does not fail gracefully, but with a slightly cryptic error message about the URL being different (where the configured URL comes back as the emtpy string).

[tkruse]

The error message should be improved if possible.

What I can imagine as a change is this: We consider the URL from .rosinstall as stating the user intention, and we select among all remotes the one that matches this URL (which commonly would be 'origin'.Do you think that would work?

[NikolausDemmel]

What I can imagine as a change is this: We consider the URL from .rosinstall as stating the user intention, and we select among all remotes the one that matches this URL (which commonly would be 'origin'.Do you think that would work?

I think that would be perfect. Remains to be decided what to do if multiple remotes have the same URL (which I guess could be just refusing service, since I would assume it is not a valid use case, and if so, very rare... but then again, the same could be said about my usecase :-P).

[tkruse]

I'd say if one of the multiples is origin, choose that, else fail.

[alberth]

I pondered a bit about this problem, and you can improve by adding a specific name for ros.
This would boil down to the following rules:

1. if there is a remote-name named "ROSorigin" (or some other clearly unique ros-related name) take that.
2. If there is a single remote-name, use it (this would be 'origin' for non-expert users)
3. If there are several remote-names (always true at this point), and they all point to the same remote-host, take any (technically, there is no ambiguity, but see below)
4. We have several remote-names pointing to several remote-hosts, euhm, we don't know! (see below)

Both 3 and 4 are in the expert user domain wrt to remote host specifications, or it would have picked 2. Such users are capable of adding a ROSorigin remote-name (which leads to picking 1). As such, I see no value in magically picking 'origin' in 4, unless you want to preserve backwards compatibility.

Case 3 is technically not ambiguous, but may become one, if you store the remote-name elsewhere (and thus decouple it from checking it stays a '3' case).

Similar reasoning can be somewhat applied to case 2, for all remote-names other than 'origin'. (Any other name may indicate an expert user. On the other hand, github also provides instructions to change remote names, which some new users may follow, without real understanding of how to extend that to the general case.)

[tkruse]

If we want a possibility to disambiguate in the case of multiple (different) remotes, we do have several choices. We can use "origin", we can use additional information in .rosinstall, we can use special names.
If we use additional information or special names, we create new confusion if there is both a remote named "origin" and some data disambiguating. So If we did that I would strongly prefer something very explicit, like the extra information in .rosinstall, rather than special names.

Supporting explicit information in .rosinstall would also allow the .rosinstall file to specify more complex setups, like setting up a workspace where all git repos have multiple remotes. This could help certain teams (team members would not have to create additional remotes themselves for each repo).

[alberth]

Sounds like a good solution to me

[tkruse]

Hm, mixing the nformation from the .rosintall with the information from vcstools is not that simple. The whole vcstools API is not designed to mix in information that would help select an appropriate origin.
So a simple thing to do is that if there is only one remote, use that, regardless of it's name.

@NikolausDemmel : You can start by trying how well this works for you, using this branch: https://github.com/vcstools/vcstools/tree/allow_other_remote

I have one idea how to get this through the API without too much hassle. On constructing a VCSClient, we could allow passing an arbitrary dict of VCS-specific params (default empty), and this could contain a default URL determining the URL to be selected in case of ambiguity.

[NikolausDemmel]

@NikolausDemmel : You can start by trying how well this works for you, using this branch: https://github.com/vcstools/vcstools/tree/allow_other_remote

Thanks! It looks reasonable, but in my case I have multiple remotes anyways. In any case for now I work around the issue by actually naming the desired remotes "origin". Not ideal from my point of view, but doable.

[dirk-thomas]

Closing since the repository is about to be archived: see #154.