Underlying http-fetch is supposed to be capable of handling
packed repositories just fine, so no need to special case it in
the wrapper script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, git-clone stored upstream's master in the branch named 'origin',
possibly overwriting an existing such branch.
Now you can change it by calling git-clone with '-o <other_name>'.
[jc: added ref format check, subdirectory safety, documentation
and usage string.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When clone-pack has trouble with the remote, it dies unfriendly
"EOF" error message. We cannot tell the reason why it failed
from the local end; it could be that the repository did not
exist, or configured not to serve over git-daemon, or a network
failure. At least, saying clone-pack failed makes it a bit more
meaningful.
I am not convinced yet that removing the newly created directory
is the right thing to do, so this commit leaves the new
directory behind.
Reported by Sam Ravnborg.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "--shared" option to git-clone is silently ignored if "--local" is
not specified. The manual doesn't mention such dependency. Make
"--shared" imply "--local".
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix a typo: We do not want to run the directory as command,
and want to terminate if the directory exists
Additionally, update the usage message
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds -p to mkdir and an explicit check to see if the target
directory exists (since mkdir -p doesn't throw an error if it does).
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch the following commands all clone into the local directory
"repo". If repo exists, it will still barf.
git-clone git://host.xz/repo.git
git-clone /path/to/repo/.git
git-clone host.xz:repo.git
I ended up doing the same source-to-target sed'ing for all our company
projects, so it was easier to add it directly to git-clone.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-clone doesn't quote the full path to the destination directory,
which causes it to fail if the path contains spaces or other characters
interpreted by the shell.
[jc: obviously I was not careful enough. Pavel, thanks for catching.]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise, git-clone silently failed to clone a remote
repository where redirections (ie. a response with a
"Location" header line) are used.
This includes the fixes from Nick Hengeveld.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This implements the idea Daniel Barkalow came up with, to match
the remotes/origin created by clone by default to the workflow I
use myself in my guinea pig repository, to have me eat my own
dog food.
We probably would want to use either .git/refs/local/heads/*
(idea by Linus) or .git/refs/heads/origin/* instead to reduce
the local ref namespace pollution.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we let cpio to create the leading directories implicitly,
it ends up having funny perm bits (GNU cpio 2.5 and 2.6, at least).
This leaves .git/object/?? directories readable only by the owner.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The newly cloned repository by default had .git/remotes/origin
set up to track the remote master to origin, but forgot to
create the origin branch ourselves. Also it hardcoded the
assumption that the remote HEAD points at "master", which may
not always be true.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somehow I forgot to forward port these fixes. "git clone" from a
repository prepared with the latest update-server-info would fail
without this patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Taking the make command line Peter Eriksen uses, give defaults
to SHELL_PATH, TAR, CURLDIR, NO_STRCASESTR, and INSTALL.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we check the optional objects/info/alternates file at the remote
repository, we forgot to really squelch error message from rsync.
Not having that file is not a crime.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For local operations and downloading and uploading via git aware protocols,
use of $GIT_OBJECT_DIRECTORY/info/alternates is recommended on the server
side for big projects that are derived from another one (like Linux kernel).
However, dumb protocols and rsync transport needs to resolve this on the
client end, which we did not bother doing until this week.
I noticed we use "rsync -z" but most of our payload is already compressed,
which was not quite right. This commit also fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
CDPATH has two problems:
* It takes scripts to unexpected places (somebody had
CDPATH=..:../..:$HOME and the "cd" in git-clone.sh:get_repo_base
took him to $HOME/.git when he said "clone foo bar" to clone a
repository in "foo" which had "foo/.git"). CDPATH mechanism does
not implicitly give "." at the beginning of CDPATH, which is
the most irritating part.
* The extra echo when it does its thing confuses scripts further.
Most of our scripts that use "cd" includes git-sh-setup so the problem
is primarily fixed there. git-clone starts without a repository, and
it needs its own fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
As promised, this is the "big tool rename" patch. The primary differences
since 0.99.6 are:
(1) git-*-script are no more. The commands installed do not
have any such suffix so users do not have to remember if
something is implemented as a shell script or not.
(2) Many command names with 'cache' in them are renamed with
'index' if that is what they mean.
There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support is expected to be removed in the near
future.
Signed-off-by: Junio C Hamano <junkio@cox.net>
