Subject: Re: [boost] [git help] GitHub boostorg library authentication
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-10-29 00:36:56
Daniel James <daniel_at_[hidden]> writes:
> On 28 October 2013 13:23, Julian Gonggrijp <j.gonggrijp_at_[hidden]> 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
>>> ./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_at_[hidden]: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
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
> 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
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
> Passwords for https can be stored using 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!
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk