Multiple services domains per passport

[holocronweaver]

I want to use the same passport credentials across multiple service domains.

There are several ways I could think to accomplish this with git-passport. The easiest is to make the service field a delimited list of services. (I suggest comma-delimited since that is most common.) Alternatively, regex could be introduced. The latter could be useful for domains with multiple similar variations, though I haven't seen that much in the wild.

[frace]

That sounds like a good idea. I'll take this on my "consideration list".

[frace]

@holocronweaver Would you like to pull the "multidomain" branch and test if it gives suitable results? It allows a comma separated list (service = github.com, gitlab.com) of domains and checks if it matches a remote in a local .git/config.

See: https://github.com/frace/git-passport/commits/multidomain

[frace]

@holocronweaver As an alternative solution I created another branch: https://github.com/frace/git-passport/commits/multidomainsection

This would let us do the following:

[passport "github, bitbucket, gitlab"]
email = ...
name = ...

[passport "github"]
email = ...
name = ...

which would eliminate possible issues with https://github.com/frace/git-passport/issues/29

[frace]

@Ferada I don't know if you are using the tool, yet. But which route would you consider to be nicer? Personally I tend to the branch multidomainsection since it has someting in common with the config style of .gitconfig.

[tverlaan]

@frace I think the naming of a passport should be something given by the user. Eg. work/private/fun/public. This would solve #29. The URL's (or something that makes a string match) should be in the config. I'm not sure if service is correct naming. I'd probably go with url or url_matches. This could be a comma-separated list. I think this resembles the original .gitconfig the most.

Example:

[passport "private"]
email = user@example.com
name = U Ser
url = git.example.com

[passport "work"]
email = user@workexample.com
name = CEO U Ser
url = git.workexample.local,git.workexample.com

Even better would be a colon separated list, that would make it the same as fetch in .gitconfig. But then it needs proper quoting.

[frace]

@tverlaan

I think the naming of a passport should be something given by the user. Eg. work/private/fun/public.

Updated #29. I think that'd be fine, too. However it needs to be mandatory to define an unique identifier always because configparser does not allow duplicate sections.

The URL's (or something that makes a string match) should be in the config.

Agreed.

I'm not sure if service is correct naming. I'd probably go with url or url_matches.

Yes, I used url in the early days of the script but switched to service instead because it's not an url what we use actually. What about providers or maybe hubs?

Even better would be a colon separated list, that would make it the same as fetch in .gitconfig. But then it needs proper quoting.

I'd be fine with a comma separated list, but this should allow colons if we'd omit e.g. the protocol http::

In [1]: mystr = "github:gitlab:bitbucket"

In [2]: print(mystr.split(":"))
['github', 'gitlab', 'bitbucket']

[frace]

@holocronweaver @tverlaan If you don't have any further objections or ideas I will implement the requested features which will lead to a result allowing us to treat our configurations as shown below:

[passport "whateverUsersWantToPutHereUniquely"]
email = ...
name = ...
hubs = github:bitbucket:gitlab

[passport "whateverUsersWantToPutHereUniquely"]
email = ...
name = ...
hubs = github

[passport "whateverUsersWantToPutHereUniquely"]
email = ...
name = ...
hubs = gitlab

[passport "..."]
...

[holocronweaver]

Yes, I used url in the early days of the script but switched to service instead because it's not an url what we use actually. What about providers or maybe hubs?

It seems url is closest to the intent, even if it is technically incorrect. I don't think it would cause confusion considering the context and examples provided. When I first saw service I thought, "So the URLs are hardcoded for each hosting provider? Like service=github translates to github.com?" If I had to choose among alternatives, service is most intuitive. hub does not bring anything particular to mind.

I think comma separated is the more intuitive of separators, especially since this is supposed to be configured by humans. I very rarely see config files use colons.

Otherwise, I think the new config is a major improvement!

[frace]

When I first saw service I thought, "So the URLs are hardcoded for each hosting provider? Like service=github translates to github.com?"

The service option gets compared with the remote.origin.url of a .git/config of a repository. If remote.origin.url exists and matches the value of the service option then it gets listed as a selection amongst others. If there isn't any match it will list all passports including the global ID (if it exists) defined in ~/.gitconfig.

It seems url is closest to the intent, even if it is technically incorrect. I don't think it would cause confusion considering the context and examples provided.

I find url to be confusing since it isn't an URL but the plain name of the Git provider which is enough to determine if a passport matches a remote.origin.url.

If I had to choose among alternatives, service is most intuitive. hub does not bring anything particular to mind.

I'm not a native english speaker, thus it might happen that I choose ambiguous or wrong terms. ^^ What about the following:

providers
platforms
services
vendors
suppliers
hosters
hosts
provider_names
service_names

But when we use passports which are used to travel around then we could use an analogy and use one of the following or similar terms:

areas
nations
countries
regions

I think comma separated is the more intuitive of separators, especially since this is supposed to be configured by humans.

That's a very good point! Let's nail it down to use commas.

[holocronweaver]

'Hosters' is not an English word. I think hosts is the best option in the list. BTW, your English is remarkably good for a non-native speaker.

[tverlaan]

After giving this some more thought. We should name it so that people understand it represents (part of) the Remote URL. url or remotes would make it recognizable for most git users immediately. I don't think url is incorrect since a url can be anything of: github.com, git@github.com, https://github.com, git@github.com:someproject. The only thing that's technically not an url is 'github', but that would also match 'my-own-github-like-site.com'. I think a lot of people that want to use multiple passports also want to be able to have different usernames for different github projects. Entering 'github' doesn't make so much sense in that case.

Last thing; if we decide to name it url, people will start entering URLs. More advanced users will find out they can enter any part of the URL, but my bet is they won't complain about the naming in that case.

[frace]

BTW, your English is remarkably good for a non-native speaker.

Thanks a lot! You'd rather notice it if I'd talk to you in person. :)

I think hosts is the best option in the list.

So let's narrow this down a little bit and do a poll - however I'd like to add a new term to our list of candidates (the devil is in the details... ^^):

host(s)
url(s)
remote(s)
scope

host(s): -1 While I like this one it would not work very well in cases where one would apply values described by @tverlaan's last post at #31. I'd rather associate it with IP addresses, hostnames or FQDNs.

url(s): +1 I guess I could agree to this one. It seems to be generic and intuitive, although it does not express the possibility to use a plain hostname like github as a value.

remote(s): -1 I could apply almost the same arguments as to url(s). Although one could feel to be forced to use the same value as defined as a value of remotes inside .git/config.

scope: +1 Used in the sense of area of validity. Seems to be pretty generic although not as inuitive as url(s).

Btw. plural or singular for candidates host, url, remote?

[holocronweaver]

Plural for hosts and remotes, but not url.

First choice: url, since it will be intuitive to almost all users. Second choice: hosts, since most users will correctly guess its meaning.

remotes certainly is part of git nomenclature, but it doesn't have clear meaning in this context since these are not repositories, but hosting services. scope is the least intuitive of the choices IMO, though it makes sense once you are already familiar with what it is describing.

[tverlaan]

@holocronweaver if we allow string or regex based matching you don't have to put a hosting service. You could as well use the name of a certain project (that might even live on multiple hosting services).

My first choice is also url. Second choice is remotes. Since that is how git identifies the hosting service, project name, repository aka all information relevant for a user to decide which passport to use.

[frace]

So the newborn's name shall be url which gives us the following scheme and possibilities:

[passport "whateverUsersWantToPutHereUniquely"]
email = ...
name = ...
url = git-passport,gitlab,http://bitbucket.com,https://github\.(com|org)/frace

As long as a single value of the comma separated list url matches a part of the given remote.origin.url of .git/config a passport will be listed as a possible candidate and presented to the user as a selection.

A single value of the comma separated list url can be one of the following:

• URL (https://github.com/frace/git-passport)
• FQDN (github.com)
• hostname (github)
• projectname (git-passport)
• one of the above including regex (github.(org|com))

Correct?

[tverlaan]

it's pretty hard to mix string matching and regular expressions, I'd say go with string matching now (easier) and maybe add url_pattern as a second option in a later stage. Or we should mark patterns another way by using /pattern_here/.

[cfi]

Coming late to the show. But since this is still open allow me to add my comment:

1) I'd suggest to go with the singular form of wording, and I can live with url, so all is well :-) Initially I was hoping for remote but that might be misleading because a repo can have multiple remotes. Do we always want to modify (filter-tree) past commits when pushing to different remotes? No, I hope not. So consequently, if following the git naming style, origin would be a better name. But it would also just be a guess, because there's nothing preventing people from changing this name. So, yes, I think url is clear, understandable, and does not hint at associations with git terms that do not really exist.

2) For the values of the parameter just go with the usual regular expressions. Drop the comma list. Then there's no need to support multiple, possibly conflicting, parameters. Several urls such as github.com|gitlab.com can easily be entered/understood by anyone using git (=programming background).

Reason for the support of regexes has already been mentioned: To be able to specify passports on a per project base even if those projects use the same service. Note that this feature is also of interest inside a corporate environment where people might have different roles for different projects (sw_integrator, feature_owner, product_owner, ordinary_user, etc) or even multiple roles on the same project and thus must distinguish their identity by repo url.

3) If we allow regexes, there's actually sense in having this url parameter instead of just putting the value into the [passport <url>] section header. Regexes can be complicated to grok at first sight and then a concise name of that passport makes sense. Otherwise those names will be almost exact duplicates of the url parameter, and there should be no needless redundancy.

In short, I'd vote for: Keep the url parameter, make it accept regexes (and no comma separated lists), then allow "reasonable" names in the [passport <name>] section header.