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>
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>
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>
[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>
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.
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>
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>
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>
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>
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>
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).
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>
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.
