Use "origin" as remote name when initializing repositories

[koalatux]

West does not use remotes in the Git repositories it creates, it always uses URLs for fetching. But it configures a remote for the user's convenience with the name of the remote attribute in the manifest.

In our manifest files we are currently using different remotes. And for our users it is cumbersome having to look up or having to remember the remote name of each project. Our workflow could be simplified if all the remotes are just named "origin". Also custom scripts could be made simpler if they don't have to look up the remote name first.

Please add an option to create all repositories with the remote name "origin" (or what Git's global config value clone.defaultRemoteName is set to).

This could also help #257

[marc-hb]

I think I understand the issue and the idea makes sense to me, but it seems quite low priority considering there is one-line workaround:

west forall -c 'git remote rename $(git remote | grep -e my_upstream1 -e my_uptream2) origin'

(tested)

[koalatux]

What about adding both remotes for backwards-compatibility?

[marc-hb]

You mean both the remote name from the west manifest and the git default? Why not but both the user/configuration interface and implementation should be kept simple. As you noted, west itself does not rely on remotes: this is a mere convenience feature, not a core feature so this could easily creep out of west scope. Convenience features can easily spiral out of control because conveniences tend to depend on personal taste and vary greatly across users and use cases. People who have "advanced" and/or unusual remote needs can very easily write a custom script that implements the perfect git remote convenience... for them.

[koalatux]

The simplest approach would be to make a breaking change. Use "origin" (or the configured git default remote name) and also stop setting the env variable WEST_PROJECT_REMOTE in the forall command to make it less confusing. But I don't want to upset anyone.

[koalatux]

Even now WEST_PROJECT_REMOTE isn't 100% reliable anyway. If a remote gets renamed in a manifest a workspace which was created before the rename is configured using the old name but running the forall command will contain the new name in WEST_PROJECT_REMOTE.

[marc-hb]

because conveniences tend to depend on personal taste and vary greatly across users and use cases.

The simplest approach would be to make a breaking change. [...] But I don't want to upset anyone.

Right, we are never going to break some people's assumptions and scripts just for the convenience of some other use cases. That bar is much higher; backwards-compatibility matters and the default behavior should not change without a very strong reason.

Speaking of use cases...

In our manifest files we are currently using different remotes. And for our users it is cumbersome having to look up or having to remember the remote name of each project.

... I just realized you never explained why your users need git remotes on a regular basis. west update is normally in charge of fetching, and pushing is 1. generally to a limited number of repos 2. often to a fork (e.g.: a Github fork) = a different remote.

[marc-hb]

I just found another workaround: if you don't use remote in west.yml and only full urls instead, then west defaults to origin. Of course that requires a lot of url duplication; not great.

If a remote gets renamed in a manifest a workspace which was created before the rename is configured using the old name but running the forall command will contain the new name in WEST_PROJECT_REMOTE.

Good point: providing that specific variable was probably not a great idea. I just submitted a clarification in #944.