Allow renaming default "origin" remote

[carlescufi]

Fishing for feedback with this issue. Would it be possible to allow users to rename the default remote ("origin") to whatever they like (say for example "upstream") and still be able to use west?

[ulfalizer]

If this something people want to do? I've only ever seen origin point to the upstream repository you cloned from, and that's hardcoded in Git (unless you change it by passing --origin to git clone).

[carlescufi]

@ulfalizer origin is arbitrary and this is how many people work (me included). In my view it's much cleaner to have origin point at your fork and upstream to the original shared repo.

[carlescufi]

@ulfalizer I tend to clone my fork first, and then add upstream. In this case, when working with west, this is harder since the manifest is shared and pointing at upstreams.

[carlescufi]

Thinking about it a bit more, I think we could by default use the name manifest-remote or similar perhaps for the remote that is declared by the manifest itself?

[carlescufi]

CC @tejlmand @mbolivar thoughts?

[carlescufi]

In fact, and since we host in GitHub, it's useful to be able to maintain the terminology used by it, which is upstream for the shared, common repo: https://help.github.com/articles/configuring-a-remote-for-a-fork/

[ulfalizer]

How are people meant to work with the whole manifest thing btw? Do we expect them to clone their own repos, and then hand-edit the manifest to point to those?

Seems super-awkward, but don't know what other options there are.

[carlescufi]

@ulfalizer

How are people meant to work with the whole manifest thing btw? Do we expect them to clone their own repos, and then hand-edit the manifest to point to those?

That is a key question, thanks for pointing it out because I find myself lacking clarity in the same area.
Let's try to summarize the issue:

1. There's a set of N upstream repos and M user forks (not every user will fork every repo)
2. Users need a way to add their own user forks. This can be done either by:
   2.a) using the manifest itself (i.e. forking the manifest)
   2.b) adding remotes with Git on the local repos cloned by west with the default manifest
3. Users need to be able to fetch from upstream and rebase their branches and user forks
4. Users need to be able to push to their user forks (and optionally directly upstream for projects that don't use code review)

I think we need to clarify how we are going to achieve all the above.

[mbolivar]

I think we need to clarify how we are going to achieve all the above.

Yup, the developer workflow is still TBD with west; this is one of the big remaining challenges discussed at the TSC presentation.

In a repo + Android context, you would likely:

• push into Gerrit's magic ref namespace to set up pull requests for review
• set up your own remotes by hand with git commands for personal work and sharing with other developers as desired

I think we're probably going to need to experiment a bit with west since we don't have Gerrit. Personally, though, I think that figuring out multi-repo CI is a harder and more important problem.

[carlescufi]

Conclusion for this issue:
Name the remote as per the remote field in the manifest.