setup_gdg is used as abbreviation for setup_git_directory_gently.
The work tree can be specified using the environment variable
GIT_WORK_TREE and the config option core.worktree (the environment
variable has precendence over the config option). Additionally
there is a command line option --work-tree which sets the
environment variable.
setup_gdg does the following now:
GIT_DIR unspecified
repository in .git directory
parent directory of the .git directory is used as work tree,
GIT_WORK_TREE is ignored
GIT_DIR unspecified
repository in cwd
GIT_DIR is set to cwd
see the cases with GIT_DIR specified what happens next and
also see the note below
GIT_DIR specified
GIT_WORK_TREE/core.worktree unspecified
cwd is used as work tree
GIT_DIR specified
GIT_WORK_TREE/core.worktree specified
the specified work tree is used
Note on the case where GIT_DIR is unspecified and repository is in cwd:
GIT_WORK_TREE is used but is_inside_git_dir is always true.
I did it this way because setup_gdg might be called multiple
times (e.g. when doing alias expansion) and in successive calls
setup_gdg should do the same thing every time.
Meaning of is_bare/is_inside_work_tree/is_inside_git_dir:
(1) is_bare_repository
A repository is bare if core.bare is true or core.bare is
unspecified and the name suggests it is bare (directory not
named .git). The bare option disables a few protective
checks which are useful with a working tree. Currently
this changes if a repository is bare:
updates of HEAD are allowed
git gc packs the refs
the reflog is disabled by default
(2) is_inside_work_tree
True if the cwd is inside the associated working tree (if there
is one), false otherwise.
(3) is_inside_git_dir
True if the cwd is inside the git directory, false otherwise.
Before this patch is_inside_git_dir was always true for bare
repositories.
When setup_gdg finds a repository git_config(git_default_config) is
always called. This ensure that is_bare_repository makes use of
core.bare and does not guess even though core.bare is specified.
inside_work_tree and inside_git_dir are set if setup_gdg finds a
repository. The is_inside_work_tree and is_inside_git_dir functions
will die if they are called before a successful call to setup_gdg.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* db/remote:
Move refspec pattern matching to match_refs().
Update local tracking refs when pushing
Add handlers for fetch-side configuration of remotes.
Move refspec parser from connect.c and cache.h to remote.{c,h}
Move remote parsing into a library file out of builtin-push.
Also, the patch makes the error messages more verbose. Helps when
diagnosing connect problems on weird systems.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git notify the user about host resolution/connection attempts.
This is useful both as a progress indicator on slow links, and helps
reassure the user there are no firewall problems.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At least in Linux glibc, "getaddrinfo()" has a very irritating feature (or
bug, who knows..).
Namely if you pass it in an empty string for the service name, it will
happily and quietly consider it identical to a NULL port pointer, and
return port number zero and no errors. Which obviously will not work.
Maybe that's what it's really expected to do, although the man-page for
getaddrinfo() certainly implies that it's a bug.
So when somebody passes me a "please pull" request pointing to something
like the following
git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
(note the extraneous colon at the end of the host name), git would happily
try to connect to port 0, which would generally just cause the remote to
not even answer, and the "connect()" will take a long time to time out.
So to work around the glibc feature/bug, just notice this empty port case
automatically. Also, add the port information to the error information
when it fails to look up (maybe it's the host-name that fails, maybe it's
the port-name - we should print out both).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, git_connect() returned the same fd twice or two
separate fds, depending on the way the connection was made (when
we are talking to the other end over a single socket, we used
the same fd twice, and when our end is connected to a pipepair
we used two).
This forced callers who do close() and dup() to really care
which was which, and most of the existing callers got this
wrong, although without much visible ill effect. Many were
closing the same fd twice when we are talking over a single
socket, and one was leaking a fd.
This fixes it to uniformly use two separate fds, so if somebody
wants to close only reader side can just do close() on it
without worrying about it accidentally also closing the writer
side or vice versa.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a mechanical clean-up of the way *.c files include
system header files.
(1) sources under compat/, platform sha-1 implementations, and
xdelta code are exempt from the following rules;
(2) the first #include must be "git-compat-util.h" or one of
our own header file that includes it first (e.g. config.h,
builtin.h, pkt-line.h);
(3) system headers that are included in "git-compat-util.h"
need not be included in individual C source files.
(4) "git-compat-util.h" does not have to include subsystem
specific header files (e.g. expat.h).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to say
git send-pack $URL :refs/heads/$branch
to delete the named remote branch. The refspec $src:$dst means
replace the destination ref with the object known as $src on the
local side, so this is a natural extension to make an empty $src
mean "No object" to delete the target.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the refname matching logic used to decide which ref
is updated with git-send-pack. We used to error out when
pushing 'master' when the other end has both 'master' branch and
a tracking branch 'remotes/$name/master' but with this, 'master'
matches only 'refs/heads/master' when both and no other 'master'
exist.
Pushing 'foo' when both heads/foo and tags/foo exist at the
remote end is still considered an error and you would need to
disambiguate between them by being more explicit.
When neither heads/foo nor tags/foo exists at the remote,
pushing 'foo' when there is only remotes/origin/foo is not
ambiguous, while it still is ambiguous when there are more than
one such weaker match (remotes/origin/foo and remotes/alt/foo,
for example).
Signed-off-by: Junio C Hamano <junkio@cox.net>
git_connect() can return 0 if we use git protocol for example.
Users of this function don't know and don't care if a process
had been created or not, and to avoid them to check it before
calling finish_connect() this patch allows finish_connect() to
take a null pid. And in that case return 0.
[jc: updated function signature of git_connect() with a comment on
its return value. ]
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use "add_to_string" instead of "sq_quote" and "snprintf", so
that there is no memory allocation and no memory leak.
Also check if the command is too long to fit into the buffer
and die if this is the case, instead of truncating it to the
buffer size.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When build a pack for a push we query the remote copy for existant
heads. These are used to prune unnecessary objects from the pack.
As we receive the remote references in get_remote_heads() we validate
the reference names via check_ref() which includes a length check;
rejecting those >45 characters in size.
This is a miss converted change, it was originally designed to reject
messages which were less than 45 characters in length (a 40 character
sha1 and refs/) to prevent comparing unitialised memory. check_ref()
now gets the raw length so check for at least 5 characters.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Like xmalloc and xrealloc xstrdup dies with a useful message if
the native strdup() implementation returns NULL rather than a
valid pointer.
I just tried to use xstrdup in new code and found it to be missing.
However I expected it to be present as xmalloc and xrealloc are
already commonly used throughout the code.
[jc: removed the part that deals with last_XXX, which I am
finding more and more dubious these days.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This abstracts away the size of the hash values when copying them
from memory location to memory location, much as the introduction
of hashcmp abstracted away hash value comparsion.
A few call sites were using char* rather than unsigned char* so
I added the cast rather than open hashcpy to be void*. This is a
reasonable tradeoff as most call sites already use unsigned char*
and the existing hashcmp is also declared to be unsigned char*.
[jc: Splitted the patch to "master" part, to be followed by a
patch for merge-recursive.c which is not in "master" yet.
Fixed the cast in the latter hunk to combine-diff.c which was
wrong in the original.
Also converted ones left-over in combine-diff.c, diff-lib.c and
upload-pack.c ]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: I needed to hand merge the changes to the updated codebase,
so the result needs to be checked.]
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
All but one callers have ignore the return value from this
function, but the only caller, builtin-tar-tree.c::remote_tar(),
assumed it returns non-zero on failure and zero on success. The
implementation however was returning either the waited pid
(which must be the same as its input) or -1 (an error).
Fix this thinko, while getting rid of an assignment of return
value from waitpid() into a variable of type int.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-peek-remote able to basically do everything that
git-ls-remote does (but obviously just for the native protocol, so no
http[s]: or rsync: support).
The default behaviour is the same, but you can now give a mixture of
"--refs", "--tags" and "--heads" flags, where "--refs" forces
git-peek-remote to only show real refs (ie none of the fakey tag lookups,
but also not the special pseudo-refs like HEAD and MERGE_HEAD).
The "--tags" and "--heads" flags respectively limit the output to just
regular tags and heads, of course.
You can still also ask to limit them by name too.
You can combine the flags, so
git peek-remote --refs --tags .
will show all local _true_ tags, without the generated tag lookups
(compare the output without the "--refs" flag).
And "--tags --heads" will show both tags and heads, but will avoid (for
example) any special refs outside of the standard locations.
I'm also planning on adding a "--ignore-local" flag that allows us to ask
it to ignore any refs that we already have in the local tree, but that's
an independent thing.
All this is obviously gearing up to making "git fetch" cheaper.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
errno was used after it could've been modified by a subsequent library call.
Spotted by Morten Welinder.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was reported that under one implementation of socks client
"git clone" fails with "error: waitpid failed (No child processes)",
because "git" is spawned after setting SIGCHLD to SIG_IGN.
Arguably it may be a broken setting, but we should protect
ourselves so that we can get reliable results from waitpid() for
the children we care about.
This patch resets SIGCHLD to SIG_DFL in three places:
- connect.c::git_connect() - initiators of git native
protocol transfer are covered with this.
- daemon.c::main() - obviously.
- merge-index.c::main() - obviously.
There are other programs that do fork() but do not waitpid():
http-push, imap-send. upload-pack does not either, but in the
case of that program, each of the forked halves runs exec()
another program, so this change would not have much effect
there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Trivial fixup for fork() callsites which do not check for errors.
Signed-off-by: Paul T Darga <pdarga@umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add client side sending of "\0host=%s\0" extended
arg for git native protocol, backwards compatibly.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, fetched refs are output in the order the remote side
happened to send them. This changes the order to match the
order of refs that were given on the command line. To the
existing core callers (git-fetch and git-clone) this does not
make any difference, but for other Porcelain use, it would be
more intuitive.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The strncmp for ACK was ACK does not include the final space.
Presumably either we should either remove the trailing space,
or compare 4 chars (as this patch does).
'path' is sometimes strdup'ed, but never freed.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
remove environment variables relating to the current repository
before execing the 'remote' half of a local push or pull operation
[jc: the original from Matt spelled out the environment variable
names, which I changed to the preprocessor symbols defined in
cache.h. Also it missed GRAFT_ENVIRONMENT.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the protocol between git-send-pack/git-receive-pack
in a backward compatible way to allow failures at the receiving
end to be propagated back to the sender. Most notably, versions
of git-push before this could not notice if the update hook on
the receiving end refused to update the ref for its own policy
reasons.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow IPv6address/IPvFuture enclosed by [] in URLs, like:
git push '[3ffe:ffff:...:1]:GIT/git'
or
git push 'ssh://[3ffe:ffff:...:1]/GIT/git'
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
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>
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>
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>
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>
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.
