tito should not assume git remote is named `origin`.

[jflorian]

Sometimes I want to repackage software with local mods. In these cases I'd prefer to reserve origin for the true origin, the upstream source. However, because tito has origin hard-coded in get_git_repo_url() of common.py I have no choice but to compromise the naming of my remotes. Ideally this value would be pulled instead from a config file.

[jmrodri]

Interesting. It is definitely true we look at the origin url. We could probably make it configurable for the repo and if not present default to origin. Do you have an example repo that uses your setup that I could look at?

[jflorian]

@jmrodri , unfortunately I don't have any examples that are fully, publicly accessible. However, I can share the setup of remotes for one particular example:

$ git remote -v
myfork  ssh://[email protected]/forks/jflorian/koji.git (fetch)
myfork  ssh://[email protected]/forks/jflorian/koji.git (push)
origin  ssh://[email protected]/koji.git (fetch)
origin  ssh://[email protected]/koji.git (push)
upstream        https://pagure.io/koji.git (fetch)
upstream        https://pagure.io/koji.git (push)

In this example, I started with the Koji repo from upstream (the Fedora Project) and made myfork from that on their same Pagure instance. That's enough to develop and share those developments with upstream. However, for our local builds, I want to use our Koji but it's restricted with allowed_scms referencing only our private Pagure instance (origin). In this example, origin is very much a misnomer. (I suppose one could consider it the origin of our changes, but those are minuscule within the bigger picture of the overall project.)

I tried to name my remotes here in a way that makes it apparent what goes where, but I'm regularly working in over 60 git repos and need all the clarity I can get -- it's too easy to forget the workflow protocol for each repo. tito helps immensely in removing much of that burden, but I fight it in this one regard.

Does that help?

[domcleal]

Do you have an example repo that uses your setup that I could look at?

I don't think this is specific to a particular repo or project - remote names can be set in any repo (i.e. a local clone). I have this same issue with tito projects, but because I normally use the remote name "project" instead of "origin" in all of my local clones so I know exactly where I'm pushing to (git clone ...; git remote rename origin project).

It'd probably need to be configurable in .titorc so the user can change it to suit their environment, rather than being in the project's tito.props.

[dgoodwin]

Tricky though as if it has to be in ~/.titorc, it seems like something unlikely to match for all git repos that user checks out. Would need to be in ~/.titorc, but repo specific.

[jflorian]

@dgoodwin, agreed. I definitely have plenty of repos where the origin is very much local/private.

[domcleal]

Good point - perhaps a $PWD/.titorc should be supported to override ~/.titorc on a per-repo basis, allowing users to customise behaviour either way.

[stevekuznetsov]

Why wouldn't it be appropriate to place this in ${repo}/.tito/tito.props? That would allow for it to be repo-specific without any extra mapping necessary.

[dgoodwin]

Yeah that would work, I think that's roughly what domclean was proposing as well.