On 28 October 2013 13:23, Julian Gonggrijp 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.

On 29 October 2013 04:36, Dave Abrahams 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.

On Tue, Oct 29, 2013 at 5:54 AM, Daniel Pfeifer wrote:

2013/10/29 Daniel James :

...

On 29 October 2013 04:36, Dave Abrahams 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

On Tue, Oct 29, 2013 at 5:45 AM, Daniel James 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 Tue, Nov 19, 2013 at 9:58 AM, Daniel James wrote:

On 19 November 2013 14:19, Beman Dawes wrote:

...

On Tue, Oct 29, 2013 at 5:45 AM, Daniel James

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