-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple services domains per passport #28
Comments
That sounds like a good idea. I'll take this on my "consideration list". |
@holocronweaver Would you like to pull the "multidomain" branch and test if it gives suitable results? It allows a comma separated list ( See: https://github.com/frace/git-passport/commits/multidomain |
@holocronweaver This would let us do the following:
which would eliminate possible issues with #29 |
@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 |
@frace I think the naming of a passport should be something given by the user. Eg. work/private/fun/public. This would solve #29. Example:
Even better would be a colon separated list, that would make it the same as |
Updated #29.
Agreed.
Yes, I used
I'd be fine with a comma separated list, but this should allow colons if we'd omit e.g. the protocol
|
@holocronweaver @tverlaan
|
It seems 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! |
The
I find
I'm not a native english speaker, thus it might happen that I choose ambiguous or wrong terms. ^^
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:
That's a very good point! Let's nail it down to use commas. |
'Hosters' is not an English word. I think |
After giving this some more thought. We should name it so that people understand it represents (part of) the Remote URL. Last thing; if we decide to name it |
Thanks a lot! You'd rather notice it if I'd talk to you in person. :)
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... ^^):
Btw. plural or singular for candidates |
Plural for hosts and remotes, but not url. First choice:
|
@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 |
So the newborn's name shall be
As long as a single value of the comma separated list A single value of the comma separated list
Correct? |
it's pretty hard to mix string matching and regular expressions, I'd say go with string matching now (easier) and maybe add |
Coming late to the show. But since this is still open allow me to add my comment:
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.
In short, I'd vote for: Keep the |
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.The text was updated successfully, but these errors were encountered: