Conversation
|
I thought this was ready, but in testing it on a host with a blank git config I'm running into some auth issues. Will pick it up again next week. |
|
aha; I've been testing on a debian server of mine and the git there is old: 2.11.0. There's no support for wildcard matching in credential helper URLs in that release. I can't for the life of me track down what our minimum supported git version is, but once I figure that out I'll decide if we should indeed ship a wildcard like this or not. |
|
Ah, TIL that wildcard support doesn't go all the way back. 🤔 An alternative could be to additionally configure |
|
That was going to be my suggestion since wildcarding only landed as recently as 2020(!). I'll retool for that. |
|
Updated this to emit multiple cred helper configs as per above discussion; tomorrow I'll manually QA this and mark it ready |
When there are stored credentials for `example.com`, allow using them to authenticate requests to `gist.example.com` as well.
|
Ok, this is ready to review. I can't request you @mislav but you still might want to take a look. |
samcoe
left a comment
There was a problem hiding this comment.
Code looks good to me. I left some questions about the changes working with enterprises, but my knowledge of enterprise gist hostnames is basically 0 so my assumption is that this works properly and my understanding is off.
| if strings.HasPrefix(gistHost, "gist.") { | ||
| credHelperKeys = append(credHelperKeys, gistGitCredentialHelperKey(hostname)) | ||
| } |
There was a problem hiding this comment.
Same question as above about this working for enterprise.
mislav
left a comment
There was a problem hiding this comment.
Fantastic; thank you!
When there are stored credentials for
example.com, allow using them to authenticate requests togist.example.comas well.TODO
gh auth logingit credential logic to configure[credential "https://*.github.com"]instead of[credential "https://github.com"]Ref. #2449, #2995