Re: [PATCH][v2] http authentication via prompts (with correct line lengths)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Amos King <amos.l.king@xxxxxxxxx> writes:

> Junio,
>
> I'm working with Mike on the http auth stuff, and I was testing out
> your patch.  I can get it to work for fetch but push is giving me some
> grief.  Looking through the code I noticed that online 219 of
> http-push.c that http_init is being called with NULL instead of a
> remote.  If I pass in the remote then there is no remotre-url.  I've
> been digging around and can't find where or when that is being set.
> It has been a while since I worked with C but I'd love to jump in and
> help out here.  Can you point me in the right direction to get the
> remote->url[0] set for the http_auth_init to use?

Daniel is the primary culprit who introduced the transport abstraction,
and I think he muttered something about his work-in-progress that involves
in some change in the API.  Perhaps he has some insights here?

Naah.  I forgot that the transport abstraction on the fetch side is much
more integrated but curl_transport_push() simply launches http-push.c that
has a world on its own.  Worse yet, "remote" in http-push.c is not even
the "struct remote"; it is something private to http-push.c called "struct
repo".

I am not sure how much work would be involved in converting (or if it is
even worth to convert) http-push.c to fit better into the transport API,
but if that is feasible, it might be a better longer-term solution.
Right now, builtin-push.c does all the remote inspection and when
http-push is called, the latter gets the information at the lowest level
only; the higher level information such as what nickname was used by the
user to initiate the "git push" process and whether the refspecs came from
the command line or from the config are all lost, which is quite sad.

But as a much lower impact interim solution, I suspect that you can fake a
minimally usable remote.  The http_push() codepath only cares about
remote->http_proxy and remote->url settings as far as I can tell, so
perhaps you can start (with a big warning that the remote you are creating
is a fake one) by filling the absolute minimum?

That is, something along these lines (this comes on top of an obvious
patch that renames existing "remote" variable in http-push. to "repo").

diff --git a/http-push.c b/http-push.c
index dfbb247..f04ac74 100644
--- a/http-push.c
+++ b/http-push.c
@@ -2197,6 +2197,7 @@ int main(int argc, char **argv)
 	int new_refs;
 	struct ref *ref;
 	char *rewritten_url = NULL;
+	struct remote *remote;
 
 	git_extract_argv0_path(argv[0]);
 
@@ -2258,12 +2259,14 @@ int main(int argc, char **argv)
 	if (!repo->url)
 		usage(http_push_usage);
 
+	remote = remote_get(repo->url);
+
 	if (delete_branch && nr_refspec != 1)
 		die("You must specify only one branch name when deleting a remote branch");
 
 	memset(remote_dir_exists, -1, 256);
 
-	http_init(NULL);
+	http_init(remote);
 
 	no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux