On 05/02/2016 10:31 AM, Mike Hommey wrote:
On Mon, May 02, 2016 at 06:56:54AM +0200, Torsten Bögershausen wrote:
On 05/01/2016 08:02 AM, Mike Hommey wrote:
+ if (flags & CONNECT_DIAG_URL) {
printf("Diag: url=%s\n", url ? url : "NULL");
printf("Diag: protocol=%s\n", prot_name(protocol));
printf("Diag: hostandport=%s\n", hostandport ? hostandport :
"NULL");
+ printf("Diag: userandhost=%s\n", host ? host : "NULL");
+ printf("Diag: port=%s\n", port ? port : "NONE");
printf("Diag: path=%s\n", path ? path : "NULL");
conn = NULL;
Does it make sense to write the host twice?
If things are cleaned up, would something like this make sense ?
printf("Diag: url=%s\n", url ? url : "NULL");
printf("Diag: protocol=%s\n", prot_name(protocol));
printf("Diag: user=%s\n", user ? user : "NULL");
printf("Diag: host=%s\n", host ? host : "NULL");
printf("Diag: port=%s\n", port ? port : "NONE");
printf("Diag: path=%s\n", path ? path : "NULL");
That's what I'm converging towards, in the end. There is one thing that
needs hostandport, though: the git protocol host header. But I don't
really like that parse_connect_url would return user, host, port, *and*
hostandport. How about "reconstructing" hostandport in that case, adding
square brackets when the host contains colons?
BTW, the git protocol currently doesn't reject urls with users and
doesn't seem to handle them properly either. My changes would fix this
by separating user and host at the parse_connect_url level, but the
question then is what to do when there is a user part? die()?
Mike
That is what happening:
git clone git://x...@git.kernel.org/pub/scm/git/git.git
Cloning into 'git'...
fatal: Unable to look up x...@git.kernel.org (port 9418) (Name or service
not known)
And that may explain, why we have different handling of ssh vs git:
The URL-scheme for git:// simply doesn't specify a user name at all.
git://host:[port]/path/to/repo
Knowing that, the "@" will be feed into the name resolver,
and that's OK.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
