summaryrefslogtreecommitdiff
path: root/git-clone.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-05-06Be more careful with objects directory permissions on cloneLibravatar Mark Hills1-1/+4
Honour the setgid and umask when re-creating the objects directory at the destination. cpio in copy-pass mode aims to copy file permissions which causes this problem and cannot be disabled. Be explicit by copying the directory structure first, honouring the permissions at the destination, then copy the files with 0444 permissions. This also avoids bugs in some versions of cpio. Signed-off-by: Mark Hills <mark@pogo.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-28Use "=" instead of "==" in condition as it is more portableLibravatar Alex Riesen1-1/+1
At least the dash from Ubuntu's /bin/sh says: test: 233: ==: unexpected operator Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-27clone: detect and fail on excess parametersLibravatar Junio C Hamano1-0/+1
"git clone [options] $src $dst excess-garbage" simply ignored excess-garbage without giving any diagnostic message. Fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-30Silence cpio's "N blocks" output when cloning locallyLibravatar Bryan Donlan1-1/+5
Pass --quiet to cpio in git-clone to hide the (confusing) "0 blocks" message. For compatibility with operating systems which might not support GNUisms, the presence of --quiet is probed for by grepping cpio's --help output. Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-29clone: support cloning full bundlesLibravatar Santi Béjar1-7/+30
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>
2008-02-20git-clone.sh: properly configure remote even if remote's head is danglingLibravatar Gerrit Pape1-5/+13
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>
2007-12-19clone: fix options '-o' and '--origin' to be recognised againLibravatar Marco Roeland1-1/+1
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>
2007-12-17Merge branch 'maint'Libravatar Junio C Hamano1-5/+6
* maint: git-send-email: avoid duplicate message-ids clone: correctly report http_fetch errors
2007-12-17clone: correctly report http_fetch errorsLibravatar Jeff King1-5/+6
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>
2007-12-12Fix clone not to ignore depth when performing a local cloneLibravatar Charles Bailey1-1/+4
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>
2007-12-11git-clone: print an error message when trying to clone empty repoLibravatar Jeff King1-1/+2
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>
2007-11-28Replace instances of export VAR=VAL with VAR=VAL; export VARLibravatar Johannes Schindelin1-1/+1
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>
2007-11-08sh-setup: don't let eval output to be shell-expanded.Libravatar Pierre Habouzit1-1/+1
The previous patch missed the same construct in git-clone. Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-11-05Migrate git-clone to use git-rev-parse --parseoptLibravatar Pierre Habouzit1-45/+56
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-03git-clone: honor "--" to end argument parsingLibravatar Heikki Orsila1-1/+4
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
2007-10-28honor the http.sslVerify option in shell scriptsLibravatar Aurelien Bompard1-1/+2
Signed-off-by: Aurélien Bompard <aurelien@bompard.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-13git-clone: improve error message if curl program is missing or not executableLibravatar Gerrit Pape1-1/+5
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>
2007-08-20git clone: do not issue warning while cloning locally across filesystemsLibravatar Junio C Hamano1-1/+4
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>
2007-08-15git-clone: allow --bare cloneLibravatar Junio C Hamano1-1/+6
This is a stop-gap to work around problem with git-init without intrusive changes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01git-clone: aggressively optimize local clone behaviour.Libravatar Junio C Hamano1-29/+35
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>
2007-07-05make git-clone GIT_WORK_TREE awareLibravatar Matthias Lederhofer1-7/+18
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>
2007-07-05git-clone: split up long &&-command-chain and use a function for cleanupLibravatar Matthias Lederhofer1-4/+13
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-13/+13
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Merge branch 'jo/init'Libravatar Junio C Hamano1-1/+1
* jo/init: Quiet the output from git-init when cloning, if requested. Add an option to quiet git-init.
2007-07-02git-clone: fetch possibly detached HEAD over dumb httpLibravatar Sven Verdoolaege1-0/+11
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>
2007-06-27Quiet the output from git-init when cloning, if requested.Libravatar Jeffrey C. Ollie1-1/+1
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>
2007-06-20Cloning from a repo without "current branch"Libravatar Nanako Shiraishi1-7/+13
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>
2007-06-08Merge branch 'ar/clone'Libravatar Junio C Hamano1-1/+1
* ar/clone: Fix clone to setup the origin if its name ends with .git
2007-06-07War on whitespaceLibravatar Junio C Hamano1-3/+2
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>
2007-06-06Fix clone to setup the origin if its name ends with .gitLibravatar Alex Riesen1-1/+1
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>
2007-05-14Fix git-clone buglet for remote case.Libravatar Junio C Hamano1-2/+2
c2f599e09fd0496413d1744b5b89b9b5c223555d introduced a buglet while cloning from a remote URL; we forgot to squelch the unnecessary error message when we try to cd to the given "remote" name, in order to see if it is a local directory. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-10git-clone: don't get fooled by $PWDLibravatar Junio C Hamano1-1/+8
If you have /home/me/git symlink pointing at /pub/git/mine, trying to clone from /pub/git/his/ using relative path would not work as expected: $ cd /home/me $ cd git $ ls ../ his mine $ git clone -l -s -n ../his/stuff.git This is because "cd ../his/stuff.git" done inside git-clone to check if the repository is local is confused by $PWD, which is set to /home/me, and tries to go to /home/his/stuff.git which is different from /pub/git/his/stuff.git. We could probably say "set -P" (or "cd -P") instead, if we know the shell is POSIX, but the way the patch is coded is probably more portable. [jc: this is updated with Andy Whitcroft's improvements] Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-20git-clone: fix dumb protocol transport to clone from pack-pruned refLibravatar Junio C Hamano1-1/+1
This forward-ports a fix from 2986c022 to git-clone. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-28http-fetch: don't use double-slash as directory separator in URLsLibravatar Gerrit Pape1-1/+1
Please see http://bugs.debian.org/409887 http-fetch expected the URL given at the command line to have a trailing slash anyway, and then added '/objects...' when requesting objects files from the http server. Now it doesn't require the trailing slash in <url> anymore, and strips trailing slashes if given nonetheless. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-19make git clone -q suppress the noise with http fetchLibravatar Chris Wright1-1/+2
We already have -q in git clone. So for those who care to suppress the noise during an http based clone, make -q actually do a quiet http fetch. Signed-off-by: Chris Wright <chrisw@sous-sol.org> Cc: Fernando Herrera <fherrera@onirica.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-24Fixup no-progress for fetch & cloneLibravatar Johannes Schindelin1-1/+1
The intent of the commit 'fetch & clone: do not output progress when not on a tty' was to make fetching and cloning less chatty when output was not redirected (such as in a cron job). However, there was a serious thinko in that commit. It assumed that the client _and_ the server got this update at the same time. But this is obviously not the case, and therefore upload-pack died on seeing the option "--no-progress". This patch fixes that issue by making it a protocol option. So, until your server is updated, you still see the progress, but once the server has this patch, it will be quiet. A minor issue was also fixed: when cloning, the checkout did not heed no_progress. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19fetch & clone: do not output progress when not on a ttyLibravatar Johannes Schindelin1-2/+4
This adds the option "--no-progress" to fetch-pack and upload-pack, and makes fetch and clone pass this option when stdout is not a tty. While at documenting that option, also document --strict and --timeout options for upload-pack. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-07git-clone --reference: work well with pack-ref'ed reference repositoryLibravatar Junio C Hamano1-35/+21
Earlier we only used loose refs to anchor already existing objects. When cloning from a repository that forked relatively long time ago from the reference repository, this made the want/have exchange by fetch-pack to do unnecessary work. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-04git-clone --reference: saner handling of borrowed symrefs.Libravatar Junio C Hamano1-1/+28
When using --reference to borrow objects from a neighbouring repository while cloning, we copy the entire set of refs under temporary "refs/reference-tmp/refs" space and set up the object alternates. However, a textual symref copied this way would not point at the right place, and causes later steps to emit error messages (which is harmless but still alarming). This is most visible when using a clone created with the separate-remote layout as a reference, because such a repository would have refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master' as its contents. Although we do not create symbolic-link based refs anymore, they have the same problem because they are always supposed to be relative to refs/ hierarchy (we dereference by hand, so it only is good for HEAD and nothing else). In either case, the solution is simply to remove them after copying under refs/reference-tmp; if a symref points at a true ref, that true ref itself is enough to ensure that objects reachable from it do not needlessly get fetched. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-31Escape --upload-pack from expr.Libravatar Shawn O. Pearce1-1/+1
Recent commit ae1dffcb28ee89a23f8d2747be65e17c8eab1690 by Junio changed the way --upload-pack was passed around between clone, fetch and ls-remote and modified the handling of the command line parameter parsing. Unfortunately FreeBSD 6.1 insists that the expression expr --upload-pack=git-upload-pack : '-[^=]*=\(.*\)' is illegal, as the --upload-pack option is not supported by their implementation of expr. Elsewhere in Git we use z as a leading prefix of both arguments, ensuring the -- isn't seen by expr. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29Replace perl code with pure shell codeLibravatar Simon 'corecode' Schubert1-44/+23
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-5/+5
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24ls-remote and clone: accept --upload-pack=<path> as well.Libravatar Junio C Hamano1-1/+3
This makes them consistent with other commands that take the path to the upload-pack program. We also pass --upload-pack instead of --exec to the underlying fetch-pack, although it is not strictly necessary. [jc: original motivation from Uwe] Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12use 'init' instead of 'init-db' for shipped docs and toolsLibravatar Nicolas Pitre1-1/+1
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-09git-clone: Make sure the master branch exists before running cat on it.Libravatar Alexandre Julliard1-1/+1
Otherwise we get an error like this on stderr: cat: [...]/.git/refs/remotes/origin/master: No such file or directory which makes it look like git-clone failed. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28Allow non-fast-forward of remote tracking branches in default cloneLibravatar Junio C Hamano1-1/+1
This changes the default remote.origin.fetch configuration created by git-clone so that it allows non-fast-forward updates. When using the separate-remote layout with reflog enabled, it does not make much sense to refuse to update the remote tracking branch just because some of them do not fast-forward. git-fetch issues warnings on non-fast-forwardness, and the user can peek at what the previous state was using the reflog. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-27Merge branch 'master' into js/shallowLibravatar Junio C Hamano1-45/+30
This is to adjust to: count-objects -v: show number of packs as well. which will break a test in this series. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-clone: lose the traditional 'no-separate-remote' layoutLibravatar Junio C Hamano1-46/+12
Finally. The separate-remote layout is so much more organized than traditional and easier to work with especially when you need to deal with remote repositories with multiple branches and/or you need to deal with more than one remote repositories, and using traditional layout for new repositories simply does not make much sense. Internally we still have code for 1:1 mappings to create a bare clone; that is a good thing and will not go away. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-clone: lose the artificial "first" fetch refspecLibravatar Junio C Hamano1-4/+4
Now we lost the "first refspec is the one that is merged by default" rule, there is no reason for clone to list the remote primary branch in the config file explicitly anymore. We still need it for the traditional layout for other reasons, though. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16git-clone: use wildcard specification for tracking branchesLibravatar Junio C Hamano1-17/+30
This stops enumerating the set of branches found on the remote side when a clone was made in the configuration file. Instead, a single entry that maps each remote branch to the local tracking branch for the remote under the same name is created. Doing it this way not only shortens the configuration file, but automatically adjusts to a new branch added on the remote side after the clone is made. Unfortunately this cannot be done for the traditional layout, where we always need to special case the 'master' to 'origin' mapping within the local branch namespace. But that is Ok; it will be going away before v1.5.0. We could also lose the "primary branch" mapping at the beginning, but that has to wait until we implement the "forbid 'git pull' when we do not have branch.$current.merge for the current branch" policy we earlier discussed. That should also be in v1.5.0 Signed-off-by: Junio C Hamano <junkio@cox.net>