[git help] GitHub boostorg library authentication
To test the modular boost docs I'm writing, I did this: git clone --recursive https://github.com/boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh ./b2 headers cd libs/system git checkout develop # did a simple edit of one file git commit -a -m "my bug fix" git push origin develop Everything ran as expected until the last step, which resulted in this: Username for 'http://github.com': That's a problem. Authentication needs to happen automatically. What steps did I miss? Thanks, --Beman
Beman Dawes wrote:
To test the modular boost docs I'm writing, I did this:
git clone --recursive https://github.com/boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh ./b2 headers cd libs/system git checkout develop # did a simple edit of one file git commit -a -m "my bug fix" git push origin develop
Everything ran as expected until the last step, which resulted in this:
Username for 'http://github.com':
That's a problem. Authentication needs to happen automatically.
What steps did I miss?
You probably want to use git@github.com:boostorg/boost.git as the remote URL. You will then authenticate automatically with your public key (assuming you have push access to boostorg). HTH! -Julian
On 28 October 2013 13:23, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
Beman Dawes wrote:
To test the modular boost docs I'm writing, I did this:
git clone --recursive https://github.com/boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh ./b2 headers cd libs/system git checkout develop # did a simple edit of one file git commit -a -m "my bug fix" git push origin develop
Everything ran as expected until the last step, which resulted in this:
Username for 'http://github.com':
That's a problem. Authentication needs to happen automatically.
What steps did I miss?
You probably want to use git@github.com:boostorg/boost.git as the remote URL. You will then authenticate automatically with your public key (assuming you have push access to boostorg).
He's trying to push a submodule, not the main repo. The urls of the submodules are set in the super-project, so the user can't choose them. The super-project can't use github's git urls as they don't allow anonymous access. I believe the super-project should be using https for submodules, rather than http. That can probably be fixed in Boost2Git. Passwords for https can be stored using password caching: https://help.github.com/articles/set-up-git#password-caching But if you'd rather use git urls in order to use your ssh key, you can use git's 'insteadOf' configuration option.
Daniel James <daniel@calamity.org.uk> writes:
On 28 October 2013 13:23, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:
Beman Dawes wrote:
To test the modular boost docs I'm writing, I did this:
git clone --recursive https://github.com/boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh ./b2 headers cd libs/system git checkout develop # did a simple edit of one file git commit -a -m "my bug fix" git push origin develop
Everything ran as expected until the last step, which resulted in this:
Username for 'http://github.com':
That's a problem. Authentication needs to happen automatically.
What steps did I miss?
You probably want to use git@github.com:boostorg/boost.git as the remote URL. You will then authenticate automatically with your public key (assuming you have push access to boostorg).
He's trying to push a submodule, not the main repo. The urls of the submodules are set in the super-project, so the user can't choose them.
Well, that's not strictly true. Being able to make such adjustments is part of the reason for the separation between git submodule init and git submodule update. After init you can go in to .gitmodules and edit URLs, etc. I admit that can be painful compared to just doing a recursive clone.
The super-project can't use github's git urls as they don't allow anonymous access. I believe the super-project should be using https for submodules, rather than http.
Why is that? Because it's possible to commit through https?
That can probably be fixed in Boost2Git.
No problem, if that's the right answer. I think you just need to edit https://github.com/ryppl/Boost2Git/blob/master/src/git_repository.cpp#L106 But won't someone complain that they can't access https behind their corporate firewall? It always seems like there's no right answer in this territory.
Passwords for https can be stored using password caching:
https://help.github.com/articles/set-up-git#password-caching
But if you'd rather use git urls in order to use your ssh key, you can use git's 'insteadOf' configuration option.
Oh, nifty; I didn't know about this! http://stackoverflow.com/questions/1722807/git-convert-git-urls-to-http-urls https://coderwall.com/p/sitezg Given the propensity of various access methods to fail for various reasons, I think we probably ought to suggest the use of insteadOf right in the instructions, no matter how we decide to write the URIs. -Dave
On 29 October 2013 04:36, Dave Abrahams <dave@boostpro.com> wrote:
The super-project can't use github's git urls as they don't allow anonymous access. I believe the super-project should be using https for submodules, rather than http.
Why is that? Because it's possible to commit through https?
Yes.
But won't someone complain that they can't access https behind their corporate firewall? It always seems like there's no right answer in this territory.
Oh right, I hadn't thought of that. Making it easy to check out probably should be the priority.
Passwords for https can be stored using password caching:
https://help.github.com/articles/set-up-git#password-caching
But if you'd rather use git urls in order to use your ssh key, you can use git's 'insteadOf' configuration option.
Oh, nifty; I didn't know about this!
http://stackoverflow.com/questions/1722807/git-convert-git-urls-to-http-urls https://coderwall.com/p/sitezg
Given the propensity of various access methods to fail for various reasons, I think we probably ought to suggest the use of insteadOf right in the instructions, no matter how we decide to write the URIs.
OK. Going back to Beman's question, I haven't tested it yet, but I think the configuration command is: git config --global url."git@github.com:boostorg/".insteadOf "http://github.com/boostorg/" This just updates the .gitconfig file, so it can be edited later if it doesn't work.
2013/10/29 Daniel James <daniel@calamity.org.uk>:
On 29 October 2013 04:36, Dave Abrahams <dave@boostpro.com> wrote:
The super-project can't use github's git urls as they don't allow anonymous access. I believe the super-project should be using https for submodules, rather than http.
Why is that? Because it's possible to commit through https?
Yes.
But won't someone complain that they can't access https behind their corporate firewall? It always seems like there's no right answer in this territory.
Oh right, I hadn't thought of that. Making it easy to check out probably should be the priority.
I am behind a corporate firewall and I cannot access git repositories through ssh. https works in both directions (pull and push).
On Tue, Oct 29, 2013 at 5:54 AM, Daniel Pfeifer <daniel@pfeifer-mail.de>wrote:
2013/10/29 Daniel James <daniel@calamity.org.uk>:
On 29 October 2013 04:36, Dave Abrahams <dave@boostpro.com> wrote:
The super-project can't use github's git urls as they don't allow anonymous access. I believe the super-project should be using https for submodules, rather than http.
Why is that? Because it's possible to commit through https?
Yes.
But won't someone complain that they can't access https behind their corporate firewall? It always seems like there's no right answer in this territory.
Oh right, I hadn't thought of that. Making it easy to check out probably should be the priority.
I am behind a corporate firewall and I cannot access git repositories through ssh. https works in both directions (pull and push).
We need to support and document both git and https so that developers can use either ssh or https. I'll test insteadOf works as intended, and then document both approaches. Won't get to it until this weekend, however. Thanks, --Beman
Daniel Pfeifer <daniel@pfeifer-mail.de> writes:
2013/10/29 Daniel James <daniel@calamity.org.uk>:
On 29 October 2013 04:36, Dave Abrahams <dave@boostpro.com> wrote:
The super-project can't use github's git urls as they don't allow anonymous access. I believe the super-project should be using https for submodules, rather than http.
Why is that? Because it's possible to commit through https?
Yes.
But won't someone complain that they can't access https behind their corporate firewall? It always seems like there's no right answer in this territory.
Oh right, I hadn't thought of that. Making it easy to check out probably should be the priority.
I am behind a corporate firewall and I cannot access git repositories through ssh. https works in both directions (pull and push).
Yes, different corporate firewalls block different protocols. But I'm happy to change to https if everyone believes that will work better overall.
On Tue, Oct 29, 2013 at 5:45 AM, Daniel James <daniel@calamity.org.uk>wrote: OK. Going back to Beman's question, I haven't tested it yet, but I
think the configuration command is:
git config --global url."git@github.com:boostorg/".insteadOf "http://github.com/boostorg/"
This just updates the .gitconfig file, so it can be edited later if it doesn't work.
I just tested this with the current boostorg repos. Worked first try. The actual command I used was: git config --global url."git@github.com:boostorg/".insteadOf " https://github.com/boostorg/" since the conversion is now using https. To test, I switched boost.system to develop, made a change to a file, then committed and pushed, both via TortoiseGit. Verified via https://github.com/boostorg/system that the push is visible. Thanks, --Beman
On 19 November 2013 14:19, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Oct 29, 2013 at 5:45 AM, Daniel James <daniel@calamity.org.uk>wrote:
OK. Going back to Beman's question, I haven't tested it yet, but I
think the configuration command is:
git config --global url."git@github.com:boostorg/".insteadOf "http://github.com/boostorg/"
This just updates the .gitconfig file, so it can be edited later if it doesn't work.
I just tested this with the current boostorg repos. Worked first try. The actual command I used was:
git config --global url."git@github.com:boostorg/".insteadOf " https://github.com/boostorg/"
You shouldn't need to do this now because Daniel Pfeifer changed it to use relative urls. All the submodules should use the same access method that you used to clone the main repo. I think it uses the default remote as the base for relative urls.
On Tue, Nov 19, 2013 at 9:58 AM, Daniel James <daniel@calamity.org.uk>wrote:
On 19 November 2013 14:19, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Oct 29, 2013 at 5:45 AM, Daniel James <daniel@calamity.org.uk wrote:
OK. Going back to Beman's question, I haven't tested it yet, but I
think the configuration command is:
git config --global url."git@github.com:boostorg/".insteadOf "http://github.com/boostorg/"
This just updates the .gitconfig file, so it can be edited later if it doesn't work.
I just tested this with the current boostorg repos. Worked first try. The actual command I used was:
git config --global url."git@github.com:boostorg/".insteadOf " https://github.com/boostorg/"
You shouldn't need to do this now because Daniel Pfeifer changed it to use relative urls. All the submodules should use the same access method that you used to clone the main repo. I think it uses the default remote as the base for relative urls.
Duh... I've verified this works as expected, and updated https://svn.boost.org/trac/boost/wiki/TryModBoost accordingly. Thanks, --Beman
On 10/28/2013 01:23 PM, Beman Dawes wrote:
git clone --recursive https://github.com/boostorg/boost.git modular-boost
https://help.github.com/articles/why-is-git-always-asking-for-my-password
participants (6)
-
Beman Dawes -
Bjorn Reese -
Daniel James -
Daniel Pfeifer -
Dave Abrahams -
Julian Gonggrijp