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>
(cherry picked from 89d844d084 commit)
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>
Now multi-head fetch is complete, let's migrate the
default configuration for new repositories created with
the "git clone" command.
The original $GIT_DIR/branches is not deprecated yet, but create
remotes directory by default from the templates as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we create a cheap local clone by pointing at the object databse
of the original repository, we forgot to take the alternates the original
repository might have had into account.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using the $GIT_OBJECT_DIRECTORY/info/alternates mechanism,
create a new repository that borrows objects from the original
repository when --shared flag is given in addition to --local.
It is worth pointing out that the "cloned" repository depends on
the original repository, so this should be used only when you
can reasonably trust that the original repository would not
disappear without your knowing.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using the information prepared with update-server-info, a truly
dumb http server can allow cloning with this client side
support.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A bit more usability enhancement, while retaining Cogito
compatibility (and fixing the "-u" flag).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While adding the documentation for these two commands, I noticed
that the name of the program on the other end (git-upload-pack)
is already almost configurable but git-clone-pack lacked command
line parameter parsing to actually use anything but default, so
I introduced --exec= like other remote commands while I was at it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- When local optimization is used, the variable repo has
already been passed through get_repo_base so there is no need
to check for .git subdirectory in there.
- Use cpio -l instead of "cp -l".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This silently adds the ".git" directory component if needed, so you
don't need to state it explicitly for the source. Also, it turns the
source into an absolute pathname when local, so that you can use
relative pathnames without losing sight of the source when we cd into
the destination.
When we are cloning a repository on a local filesystem, it is
faster to just create a hard linkfarm of .git/object hierarchy
and copy the .git/refs files. By default, the script uses the
clone-pack method, but it can be told with the -l flag to do the
hard linkfarm (falling back on recursive file copy) to replicate
the .git/object hierarchy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>