summaryrefslogtreecommitdiff
path: root/connect.c
AgeCommit message (Collapse)AuthorFilesLines
2005-11-22Fixed git:// IPv4 address problem when compiled with -DNO_IPV6.Libravatar Paul Serice1-1/+1
Failure to dereference a pointer caused incorrect initialization of the IPv4 address when calling connect() when compiled with -DNO_IPV6. With this patch and yesterday's patch for git-daemon, it should now be possible to use the native git protocol for both the client and server on Cygwin. Signed-off-by: Paul Serice <paul@serice.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21GIT: Fix compilation error in connect.cLibravatar YOSHIFUJI Hideaki / 吉藤英明1-4/+5
Fix compilation error for gcc-2.95. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21git-proxy updates.Libravatar Junio C Hamano1-7/+45
This builds on top of the git-proxy mechanism Paul Collins did, and updates its configuration mechanism. * GIT_PROXY_COMMAND environment variable is used as the catch-all fallback, as in the original. This has not changed. * Renames proxy configuration variables to core.gitproxy; this has become a multi-value variable per list discussion, most notably from suggestion by Linus. [core] ;# matches www.kernel.org as well gitproxy = netcatter for kernel.org gitproxy = netscatter for sample.xz gitproxy = none for mydomain.xz gitproxy = netcatter-default The values are command names, followed by an optional " for " and domainname; the first tail-match of the domainname determines which proxy command is used. An entry without " for " matches any domain and can be used as the default. The command name "none" is special -- it tells the mechanism not to use any proxy command and use the native git:// connection. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21proxy-command support for git://Libravatar Paul Collins1-1/+71
Here is an updated patch that first looks for GIT_PROXY_COMMAND in the environment and then git.proxycommand in the repository's configuration file. I have left the calling convention the same argv[1] is the host and argv[2] is the port. I've taken the hostname parsing verbatim from git_tcp_connect(), so it should now support an explicit port number and whatever that business with the square brackets is. (Should I move this to a helper function?) Regarding internal vs. external hosts, the proxy command can simply run netcat locally to internal hosts, so perhaps that is sufficient. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Client side support for user-relative paths.Libravatar Andreas Ericsson1-22/+33
With this patch, the client side passes identical paths for these two: ssh://host.xz/~junio/repo host.xz:~junio/repo Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28fix multi_ack.Libravatar Johannes Schindelin1-2/+3
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28git-fetch-pack: Support multi_ack extensionLibravatar Johannes Schindelin1-1/+4
The client side support for multi_ack. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28Support receiving server capabilitiesLibravatar Johannes Schindelin1-1/+15
This patch implements the client side of backward compatible upload-pack protocol extension, <20051027141619.0e8029f2.vsu@altlinux.ru> by Sergey. The updated server can append "server_capabilities" which is supposed to be a string containing space separated features of the server, after one of elements in the initial list of SHA1-refname line, hidden with an embedded NUL. After get_remote_heads(), check if the server supports the feature like if (server_supports("multi_ack")) do_something(); Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-25Revert recent fetch-pack/upload-pack updates.Libravatar Junio C Hamano1-4/+1
Let's have it simmer a bit longer in the proposed updates branch and shake the problems out. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-24git-fetch-pack: Implement client part of the multi_ack extensionLibravatar Johannes Schindelin1-1/+4
This patch concludes the series, which makes git-fetch-pack/git-upload-pack negotiate a potentially better set of common revs. It should make a difference when fetching from a repository with a few branches. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-16Squelch compiler warnings from connect.cLibravatar Junio C Hamano1-0/+1
Forgot to include necessary header file to get the function declaration. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Ignore funny refname sent from remoteLibravatar Junio C Hamano1-1/+7
This allows the remote side (most notably, upload-pack) to show additional information without affecting the downloader. Peek-remote does not ignore them -- this is to make it useful for Pasky's automatic tag following. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-14Support git+ssh:// and ssh+git:// URLLibravatar Linus Torvalds1-0/+4
It seemed to be such a stupid syntax. It's both what "ssh://" means, and it's what not specifying a protocol at _all_ means. But hey, since we already have two ways of saying "use ssh with pack-files", here's two more. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-28NO_IPV6 support for git daemonLibravatar Peter Anvin1-1/+1
2005-09-28Call it NO_IPV6 rather than hard-coding __CYGWIN__Libravatar hpa1-3/+3
2005-09-28Cygwin doesn't support IPv6 or getaddrinfo()Libravatar hpa1-0/+73
2005-08-28Merge refs/heads/portable from http://www.cs.berkeley.edu/~ejr/gits/git.git Libravatar Junio C Hamano1-2/+4
2005-08-24Support +<src>:<dst> format in push as well.Libravatar Junio C Hamano1-2/+15
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23Fix ?: statements.Libravatar Jason Riedy1-2/+4
Omitting the first branch in ?: is a GNU extension. Cute, but not supported by other compilers. Replaced mostly by explicit tests. Calls to getenv() simply are repeated on non-GNU compilers. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
2005-08-09Use GIT_SSH environment to specify alternate ssh binary.Libravatar Martin Sivak1-2/+9
[jc: I ended up rewriting Martin's patch due to whitespace breakage, but the credit goes to Martin for doing the initial patch to identify what needs to be changed.] Signed-off-by: Martin Sivak <mars@nomi.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-09[PATCH] -Werror fixesLibravatar Timo Sirainen1-1/+2
GCC's format __attribute__ is good for checking errors, especially with -Wformat=2 parameter. This fixes most of the reported problems against 2005-08-09 snapshot.
2005-08-06send-pack: allow generic sha1 expression on the source side.Libravatar Junio C Hamano1-0/+20
This extends the source side semantics to match what Linus suggested. An example: $ git-send-pack kernel.org:/pub/scm/git/git.git pu^^:master pu would allow me to push the current pu into pu, and the commit two commits before it into master, on my public repository. The revised rule for updating remote heads is as follows. $ git-send-pack [--all] <remote> [<ref>...] - When no <ref> is specified: - with '--all', it is the same as specifying the full refs/* path for all local refs; - without '--all', it is the same as specifying the full refs/* path for refs that exist on both ends; - When one or more <ref>s are specified: - a single token <ref> (i.e. no colon) must be a pattern that tail-matches refs/* path for an existing local ref. It is an error for the pattern to match no local ref, or more than one local refs. The matching ref is pushed to the remote end under the same name. - <src>:<dst> can have different cases. <src> is first tried as the tail-matching pattern for refs/* path. - If more than one matches are found, it is an error. - If one match is found, <dst> must either match no remote ref and start with "refs/", or match exactly one remote ref. That remote ref is updated with the sha1 value obtained from the <src> sha1. - If no match is found, it is given to get_extended_sha1(); it is an error if get_extended_sha1() does not find an object name. If it succeeds, <dst> must either match no remote ref and start with "refs/" or match exactly one remote ref. That remote ref is updated with the sha1 value. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-06send-pack: allow the same source to be pushed more than once.Libravatar Junio C Hamano1-7/+0
The revised code accidentally inherited the restriction that a reference can be pushed only once, only because the original did not allow renaming. This is no longer necessary so lift it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-05Fix refname termination.Libravatar Junio C Hamano1-1/+1
When a new ref is being pushed, the name of it was not terminated properly. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-03[PATCH] Fix sparse warningsLibravatar Alecs King1-3/+1
fix one 'should it be static?' warning and two 'mixing declarations and code' warnings. Signed-off-by: Alecs King <alecsk@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-03Renaming push.Libravatar Junio C Hamano1-3/+169
This allows git-send-pack to push local refs to a destination repository under different names. Here is the name mapping rules for refs. * If there is no ref mapping on the command line: - if '--all' is specified, it is equivalent to specifying <local> ":" <local> for all the existing local refs on the command line - otherwise, it is equivalent to specifying <ref> ":" <ref> for all the refs that exist on both sides. * <name> is just a shorthand for <name> ":" <name> * <src> ":" <dst> push ref that matches <src> to ref that matches <dst>. - It is an error if <src> does not match exactly one of local refs. - It is an error if <dst> matches more than one remote refs. - If <dst> does not match any remote refs, either - it has to start with "refs/"; <dst> is used as the destination literally in this case. - <src> == <dst> and the ref that matched the <src> must not exist in the set of remote refs; the ref matched <src> locally is used as the name of the destination. For example, - "git-send-pack --all <remote>" works exactly as before; - "git-send-pack <remote> master:upstream" pushes local master to remote ref that matches "upstream". If there is no such ref, it is an error. - "git-send-pack <remote> master:refs/heads/upstream" pushes local master to remote refs/heads/upstream, even when refs/heads/upstream does not exist. - "git-send-pack <remote> master" into an empty remote repository pushes the local ref/heads/master to the remote ref/heads/master. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-23Fix git protocol connection 'port' overrideLibravatar Linus Torvalds1-1/+3
It was broken by the IPv6 patches - we need to remove the ":" part from the hostname for a successful name lookup.
2005-07-23[PATCH] GIT: Try all addresses for given remote nameLibravatar YOSHIFUJI Hideaki1-28/+43
Try all addresses for given remote name until it succeeds. Also supports IPv6. Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-16Merge three separate "fetch refs" functionsLibravatar Linus Torvalds1-0/+35
It really just boils down to one "get_remote_heads()" function, and a common "struct ref" structure definition.
2005-07-13Add first cut at "git protocol" connect logic.Libravatar Linus Torvalds1-2/+81
Useful for pulling stuff off a dedicated server. Instead of connecting with ssh or just starting a local pipeline, we connect over TCP to the other side and try to see if there's a git server listening. Of course, since I haven't written the git server yet, that will never happen. But the server really just needs to listen on a port, and execute a "git-upload-pack" when somebody connects. (It should read one packet-line, which should be of the format "git-upload-pack directoryname\n" and eventually we migth have other commands the server might accept).
2005-07-08[PATCH] Use sq_quote() to properly quote the parameter to call shell.Libravatar Junio C Hamano1-30/+3
This tries to be more lenient to the users and stricter to the attackers by quoting the input properly for shell safety, instead of forbidding certain characters from the input. Things to note: - We do not quote "prog" parameter (which comes from --exec). The user should know what he is doing. --exec='echo foo' will supply the first two parameters to the resulting command, while --exec="'echo foo'" will give the first parameter, a single string with a space inside. - We do not care too much about leaking the sq_quote() output just before running exec(). Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07Mark more characters shell-safe.Libravatar Linus Torvalds1-1/+3
I still worry about just quoting things when passing it off to "ssh" or "sh -c", so I'm being anal. But _, ^ and , are certainly ok and while both ~ and @ can have speacial meaning to shell/ssh they are benign.
2005-07-05Move "get_ack()" to common git_connect functionsLibravatar Linus Torvalds1-0/+19
git-clone-pack will want it too. Soon.
2005-07-04Move ref path matching to connect.c libraryLibravatar Linus Torvalds1-0/+21
It's a generic thing for matching refs from the other side.
2005-07-04Factor out the ssh connection stuff from send-pack.cLibravatar Linus Torvalds1-0/+86
I want to use it for git-fetch-pack too.