The "humanish" part of a bundle is made removing the ".bundle" suffix.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cloning a remote repository which's HEAD refers to a nonexistent
ref, git-clone cloned all existing refs, but failed to write the
configuration for 'remote'. Now it detects the dangling remote HEAD,
refuses to checkout any local branch since HEAD refers to nowhere, but
properly writes the configuration for 'remote', so that subsequent
'git fetch's don't fail.
The problem was reported by Daniel Jacobowitz through
http://bugs.debian.org/466581
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default of pwd of MSYS's bash and /bin/pwd are to use /c/rest/of/path
notation instead of c:/rest/of/path. But the former is not supported
by programs that use the standard C runtime (instead of MSYS's
runtime). Hence, we must make sure that only drive letter notations
are generated by using pwd's -W option.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Due to a subtle typo in a shell case pattern neither alternative worked.
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The exit status from curl was accidentally lost by the
'case' statement. We need to explicitly save it so that $?
doesn't get overwritten.
This improves the error message when fetching from an http
repository which has never had update-server-info run.
Previously, it would fail to note the fetch error and
produce multiple errors about the lack of origin branches.
It now correctly suggests running git-update-server-info.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git-clone detects that it can perform a local clone it
follows a path that silently ignores the depth parameter.
Presumably if the user explicitly requests a shallow clone they
have a reason to prefer a space efficient clone of just the recent
history so bypass the local magic if the user specifies the depth
parameter.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, cloning an empty repository looked like this:
$ (mkdir parent && cd parent && git --bare init)
$ git-clone parent child
Initialized empty Git repository in /home/peff/clone/child/.git/
$ cd child
-bash: cd: child: No such file or directory
$ echo 'wtf?' | mail git@vger.kernel.org
Now we at least report that the clone was not successful.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It might be POSIX, but there are shells that do not like the
expression 'export VAR=VAL'. To be on the safe side, rewrite them
into 'VAR=VAL' and 'export VAR'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We use 'xargs cp' to emulate 'cpio -pumd'.
cpio is fed from the output of 'find --depth' without filtering out
directories. We don't need to copy directories except the empty ones, so
we need to filter out non-empty directories. Then we can use 'cp -r' and
it will not actually recurse anything.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
If the PATH lists the Windows system directories before the MSYS
directories, Windows's own incompatible sort and find commands would be
picked up. We implement these commands as functions and call the real
tools by absolute path.
Also add a dummy implementation of sync to avoid an error in git-repack.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
If the curl program is not available (or not executable), and git clone is
started to clone a repository through http, this is the output
Initialized empty Git repository in /tmp/puppet/.git/
/usr/bin/git-clone: line 37: curl: command not found
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
This patch improves the error message by checking the return code when
running curl to exit immediately if it's 126 or 127; the error output now
is
Initialized empty Git repository in /tmp/puppet/.git/
/usr/bin/git-clone: line 37: curl: command not found
Adrian Bridgett noticed this and reported through
http://bugs.debian.org/440976
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unless the user explicitly asked hardlinking with the '-l'
option, we should not say "oops we cannot hardlink as you asked
so we are copying".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes the behaviour of cloning from a repository on the
local machine, by defaulting to "-l" (use hardlinks to share
files under .git/objects) and making "-l" a no-op. A new
option, --no-hardlinks, is also added to cause file-level copy
of files under .git/objects while still avoiding the normal
"pack to pipe, then receive and index pack" network transfer
overhead. The old behaviour of local cloning without -l nor -s
is availble by specifying the source repository with the newly
introduced file:///path/to/repo.git/ syntax (i.e. "same as
network" cloning).
* With --no-hardlinks (i.e. have all .git/objects/ copied via
cpio) would not catch the source repository corruption, and
also risks corrupted recipient repository if an
alpha-particle hits memory cell while indexing and resolving
deltas. As long as the recipient is created uncorrupted, you
have a good back-up.
* same-as-network is expensive, but it would catch the breakage
of the source repository. It still risks corrupted recipient
repository due to hardware failure. As long as the recipient
is created uncorrupted, you have a good back-up.
* The new default on the same filesystem, as long as the source
repository is healthy, it is very likely that the recipient
would be, too. Also it is very cheap. You do not get any
back-up benefit, though.
None of the method is resilient against the source repository
corruption, so let's discount that from the comparison. Then
the difference with and without --no-hardlinks matters primarily
if you value the back-up benefit or not. If you want to use the
cloned repository as a back-up, then it is cheaper to do a clone
with --no-hardlinks and two git-fsck (source before clone,
recipient after clone) than same-as-network clone, especially as
you are likely to do a git-fsck on the recipient if you are so
paranoid anyway.
Which leads me to believe that being able to use file:/// is
probably a good idea, if only for testability, but probably of
little practical value. We default to hardlinked clone for
everyday use, and paranoids can use --no-hardlinks as a way to
make a back-up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If GIT_WORK_TREE is set git-clone will use that path for the
working tree.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clone supports cloning from a repo with detached HEAD,
but if this HEAD is not behind any branch tip then it
would not have been fetched over dumb http, resulting in a
fatal: Not a valid object name HEAD
Since 928c210a, this would also happen on a http repo
with a HEAD that is a symbolic link where someone has
forgotton to run update-server-info.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that git-init has an option to quiet itself, use it if the -q
option was specified on the clone command line.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the remote repository does not have a "current branch", git-clone
was confused and did not set up the resulting new repository
correctly. It did not reset HEAD from the default 'master', and did
not write the SHA1 to the master branch.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The problem is visible when cloning a local repo. The cloned
repository will have the origin url setup incorrectly: the origin name
will be copied verbatim in origin url of the cloned repository.
Normally, the name is to be expanded into absolute path.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The default of pwd of MSYS's bash and /bin/pwd are to use /c/rest/of/path
notation instead of c:/rest/of/path. But the former is not supported
by programs that use the standard C runtime (instead of MinGW's own
runtime). Hence, we must make sure that only drive letter notations
are generated by using pwd's -W option.
