summaryrefslogtreecommitdiff
path: root/git-clone.sh
Commit message (Collapse)AuthorAgeFilesLines
* clone: fix options '-o' and '--origin' to be recognised againMarco Roeland2007-12-191-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>
* Merge branch 'maint'Junio C Hamano2007-12-171-5/+6
|\ | | | | | | | | | | * maint: git-send-email: avoid duplicate message-ids clone: correctly report http_fetch errors
| * clone: correctly report http_fetch errorsJeff King2007-12-171-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>
* | Fix clone not to ignore depth when performing a local cloneCharles Bailey2007-12-121-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>
* | git-clone: print an error message when trying to clone empty repoJeff King2007-12-111-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>
* | Replace instances of export VAR=VAL with VAR=VAL; export VARJohannes Schindelin2007-11-281-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>
* | sh-setup: don't let eval output to be shell-expanded.Pierre Habouzit2007-11-081-1/+1
| | | | | | | | | | | | The previous patch missed the same construct in git-clone. Signed-off-by: Pierre Habouzit <madcoder@debian.org>
* | Migrate git-clone to use git-rev-parse --parseoptPierre Habouzit2007-11-051-45/+56
| | | | | | | | | | Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-clone: honor "--" to end argument parsingHeikki Orsila2007-11-031-1/+4
|/ | | | Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
* honor the http.sslVerify option in shell scriptsAurelien Bompard2007-10-281-1/+2
| | | | | Signed-off-by: Aurélien Bompard <aurelien@bompard.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-clone: improve error message if curl program is missing or not executableGerrit Pape2007-09-131-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>
* git clone: do not issue warning while cloning locally across filesystemsJunio C Hamano2007-08-201-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>
* git-clone: allow --bare cloneJunio C Hamano2007-08-151-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>
* git-clone: aggressively optimize local clone behaviour.Junio C Hamano2007-08-011-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>
* make git-clone GIT_WORK_TREE awareMatthias Lederhofer2007-07-051-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>
* git-clone: split up long &&-command-chain and use a function for cleanupMatthias Lederhofer2007-07-051-4/+13
| | | | | Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-021-13/+13
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jo/init'Junio C Hamano2007-07-021-1/+1
|\ | | | | | | | | | | * jo/init: Quiet the output from git-init when cloning, if requested. Add an option to quiet git-init.
| * Quiet the output from git-init when cloning, if requested.Jeffrey C. Ollie2007-06-271-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>
* | git-clone: fetch possibly detached HEAD over dumb httpSven Verdoolaege2007-07-021-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>
* Cloning from a repo without "current branch"Nanako Shiraishi2007-06-201-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>
* Merge branch 'ar/clone'Junio C Hamano2007-06-081-1/+1
|\ | | | | | | | | * ar/clone: Fix clone to setup the origin if its name ends with .git
| * Fix clone to setup the origin if its name ends with .gitAlex Riesen2007-06-061-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>
* | War on whitespaceJunio C Hamano2007-06-071-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>
* Fix git-clone buglet for remote case.Junio C Hamano2007-05-141-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>
* git-clone: don't get fooled by $PWDJunio C Hamano2007-05-101-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>
* git-clone: fix dumb protocol transport to clone from pack-pruned refJunio C Hamano2007-04-201-1/+1
| | | | | | This forward-ports a fix from 2986c022 to git-clone. Signed-off-by: Junio C Hamano <junkio@cox.net>
* http-fetch: don't use double-slash as directory separator in URLsGerrit Pape2007-03-281-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>
* make git clone -q suppress the noise with http fetchChris Wright2007-03-191-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>
* Fixup no-progress for fetch & cloneJohannes Schindelin2007-02-241-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>
* fetch & clone: do not output progress when not on a ttyJohannes Schindelin2007-02-191-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>
* git-clone --reference: work well with pack-ref'ed reference repositoryJunio C Hamano2007-02-071-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>
* git-clone --reference: saner handling of borrowed symrefs.Junio C Hamano2007-02-041-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>
* Escape --upload-pack from expr.Shawn O. Pearce2007-01-311-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>
* Replace perl code with pure shell codeSimon 'corecode' Schubert2007-01-291-44/+23
| | | | | Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* [PATCH] Rename git-repo-config to git-config.Tom Prince2007-01-281-5/+5
| | | | | Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* ls-remote and clone: accept --upload-pack=<path> as well.Junio C Hamano2007-01-241-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>
* use 'init' instead of 'init-db' for shipped docs and toolsNicolas Pitre2007-01-121-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>
* git-clone: Make sure the master branch exists before running cat on it.Alexandre Julliard2007-01-091-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>
* Allow non-fast-forward of remote tracking branches in default cloneJunio C Hamano2006-12-281-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>
* Merge branch 'master' into js/shallowJunio C Hamano2006-12-271-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>
| * git-clone: lose the traditional 'no-separate-remote' layoutJunio C Hamano2006-12-161-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>
| * git-clone: lose the artificial "first" fetch refspecJunio C Hamano2006-12-161-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>
| * git-clone: use wildcard specification for tracking branchesJunio C Hamano2006-12-161-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>
| * Explicitly add the default "git pull" behaviour to .git/config on cloneAndy Parkins2006-12-061-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without any specification in the .git/config file, git-pull will execute "git-pull origin"; which in turn defaults to pull from the first "pull" definition for the remote, "origin". This is a difficult set of defaults to track for a new user, and it's difficult to see what tells git to do this (especially when it is actually hard-coded behaviour). To ameliorate this slightly, this patch explicitly specifies the default behaviour during a clone using the "branch" section of the config. For example, a clone of a typical repository would create a .git/config containing: [remote "origin"] url = proto://host/repo.git fetch = refs/heads/master:refs/remotes/origin/master [branch "master"] remote = origin merge = refs/heads/master The [branch "master"] section is such that there is no change to the functionality of git-pull, but that functionality is now explicitly documented. Signed-off-by: Andy Parkins <andyparkins@gmail.com>
| * Merge Junio C Hamano2006-12-061-5/+5
| |\
| | * Use .git/config for storing "origin" shortcut repositoryAndy Parkins2006-11-271-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than use a separate config .git/remotes/ for remote shortcuts, this patch adds the analagous definitions to .git/config using git-repo-config calls. For example what was previously .git/remotes/origin URL: proto://host/path Pull: refs/heads/master:refs/heads/origin Is now added to .git/config as [remote "origin"] url = proto://host/path fetch = refs/heads/master:refs/heads/origin Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * | git-clone: Rename --use-immingled-remote option to --no-separate-remoteJakub Narebski2006-12-041-3/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | With making --use-separate-remote default when creating non-bare clone, there was need for the flag which would turn off this behavior. It was called --use-immingled-remote. Immingle means to blend, to combine into one, to intermingle, but it is a bit obscure word. I think it would be better to use simply --no-separate-remote as the opposite to --use-separate-remote option to git clone. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * git-clone: stop dumb protocol from copying refs outside heads/ and tags/.Junio C Hamano2006-11-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | Most notably, the original code first copied refs/remotes/ that remote side had to local, and overwrote them by mapping refs/heads/ from the remote when a dumb protocol transport was used. This makes the clone behaviour by dumb protocol in line with the git native and rsync transports. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | allow cloning a repository "shallowly"Johannes Schindelin2006-11-241-3/+16
|/ | | | | | | | | | | | By specifying a depth, you can now clone a repository such that all fetched ancestor-chains' length is at most "depth". For example, if the upstream repository has only 2 branches ("A" and "B"), which are linear, and you specify depth 3, you will get A, A~1, A~2, A~3, B, B~1, B~2, and B~3. The ends are automatically made shallow commits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
View Lorry Controller Status