1git-clone(1) 2============ 3 4NAME 5---- 6git-clone - Clone a repository into a new directory 7 8 9SYNOPSIS 10-------- 11[verse] 12'git clone' [--template=<template_directory>] 13 [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] 14 [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>] 15 [--dissociate] [--separate-git-dir <git dir>] 16 [--depth <depth>] [--[no-]single-branch] [--no-tags] 17 [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules] 18 [--[no-]remote-submodules] [--jobs <n>] [--] <repository> 19 [<directory>] 20 21DESCRIPTION 22----------- 23 24Clones a repository into a newly created directory, creates 25remote-tracking branches for each branch in the cloned repository 26(visible using `git branch --remotes`), and creates and checks out an 27initial branch that is forked from the cloned repository's 28currently active branch. 29 30After the clone, a plain `git fetch` without arguments will update 31all the remote-tracking branches, and a `git pull` without 32arguments will in addition merge the remote master branch into the 33current master branch, if any (this is untrue when "--single-branch" 34is given; see below). 35 36This default configuration is achieved by creating references to 37the remote branch heads under `refs/remotes/origin` and 38by initializing `remote.origin.url` and `remote.origin.fetch` 39configuration variables. 40 41 42OPTIONS 43------- 44-l:: 45--local:: 46 When the repository to clone from is on a local machine, 47 this flag bypasses the normal "Git aware" transport 48 mechanism and clones the repository by making a copy of 49 HEAD and everything under objects and refs directories. 50 The files under `.git/objects/` directory are hardlinked 51 to save space when possible. 52+ 53If the repository is specified as a local path (e.g., `/path/to/repo`), 54this is the default, and --local is essentially a no-op. If the 55repository is specified as a URL, then this flag is ignored (and we 56never use the local optimizations). Specifying `--no-local` will 57override the default when `/path/to/repo` is given, using the regular 58Git transport instead. 59 60--no-hardlinks:: 61 Force the cloning process from a repository on a local 62 filesystem to copy the files under the `.git/objects` 63 directory instead of using hardlinks. This may be desirable 64 if you are trying to make a back-up of your repository. 65 66-s:: 67--shared:: 68 When the repository to clone is on the local machine, 69 instead of using hard links, automatically setup 70 `.git/objects/info/alternates` to share the objects 71 with the source repository. The resulting repository 72 starts out without any object of its own. 73+ 74*NOTE*: this is a possibly dangerous operation; do *not* use 75it unless you understand what it does. If you clone your 76repository using this option and then delete branches (or use any 77other Git command that makes any existing commit unreferenced) in the 78source repository, some objects may become unreferenced (or dangling). 79These objects may be removed by normal Git operations (such as `git commit`) 80which automatically call `git gc --auto`. (See linkgit:git-gc[1].) 81If these objects are removed and were referenced by the cloned repository, 82then the cloned repository will become corrupt. 83+ 84Note that running `git repack` without the `--local` option in a repository 85cloned with `--shared` will copy objects from the source repository into a pack 86in the cloned repository, removing the disk space savings of `clone --shared`. 87It is safe, however, to run `git gc`, which uses the `--local` option by 88default. 89+ 90If you want to break the dependency of a repository cloned with `--shared` on 91its source repository, you can simply run `git repack -a` to copy all 92objects from the source repository into a pack in the cloned repository. 93 94--reference[-if-able] <repository>:: 95 If the reference repository is on the local machine, 96 automatically setup `.git/objects/info/alternates` to 97 obtain objects from the reference repository. Using 98 an already existing repository as an alternate will 99 require fewer objects to be copied from the repository 100 being cloned, reducing network and local storage costs. 101 When using the `--reference-if-able`, a non existing 102 directory is skipped with a warning instead of aborting 103 the clone. 104+ 105*NOTE*: see the NOTE for the `--shared` option, and also the 106`--dissociate` option. 107 108--dissociate:: 109 Borrow the objects from reference repositories specified 110 with the `--reference` options only to reduce network 111 transfer, and stop borrowing from them after a clone is made 112 by making necessary local copies of borrowed objects. This 113 option can also be used when cloning locally from a 114 repository that already borrows objects from another 115 repository--the new repository will borrow objects from the 116 same repository, and this option can be used to stop the 117 borrowing. 118 119-q:: 120--quiet:: 121 Operate quietly. Progress is not reported to the standard 122 error stream. 123 124-v:: 125--verbose:: 126 Run verbosely. Does not affect the reporting of progress status 127 to the standard error stream. 128 129--progress:: 130 Progress status is reported on the standard error stream 131 by default when it is attached to a terminal, unless `--quiet` 132 is specified. This flag forces progress status even if the 133 standard error stream is not directed to a terminal. 134 135--server-option=<option>:: 136 Transmit the given string to the server when communicating using 137 protocol version 2. The given string must not contain a NUL or LF 138 character. The server's handling of server options, including 139 unknown ones, is server-specific. 140 When multiple `--server-option=<option>` are given, they are all 141 sent to the other side in the order listed on the command line. 142 143-n:: 144--no-checkout:: 145 No checkout of HEAD is performed after the clone is complete. 146 147--bare:: 148 Make a 'bare' Git repository. That is, instead of 149 creating `<directory>` and placing the administrative 150 files in `<directory>/.git`, make the `<directory>` 151 itself the `$GIT_DIR`. This obviously implies the `--no-checkout` 152 because there is nowhere to check out the working tree. 153 Also the branch heads at the remote are copied directly 154 to corresponding local branch heads, without mapping 155 them to `refs/remotes/origin/`. When this option is 156 used, neither remote-tracking branches nor the related 157 configuration variables are created. 158 159--mirror:: 160 Set up a mirror of the source repository. This implies `--bare`. 161 Compared to `--bare`, `--mirror` not only maps local branches of the 162 source to local branches of the target, it maps all refs (including 163 remote-tracking branches, notes etc.) and sets up a refspec configuration such 164 that all these refs are overwritten by a `git remote update` in the 165 target repository. 166 167-o <name>:: 168--origin <name>:: 169 Instead of using the remote name `origin` to keep track 170 of the upstream repository, use `<name>`. 171 172-b <name>:: 173--branch <name>:: 174 Instead of pointing the newly created HEAD to the branch pointed 175 to by the cloned repository's HEAD, point to `<name>` branch 176 instead. In a non-bare repository, this is the branch that will 177 be checked out. 178 `--branch` can also take tags and detaches the HEAD at that commit 179 in the resulting repository. 180 181-u <upload-pack>:: 182--upload-pack <upload-pack>:: 183 When given, and the repository to clone from is accessed 184 via ssh, this specifies a non-default path for the command 185 run on the other end. 186 187--template=<template_directory>:: 188 Specify the directory from which templates will be used; 189 (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) 190 191-c <key>=<value>:: 192--config <key>=<value>:: 193 Set a configuration variable in the newly-created repository; 194 this takes effect immediately after the repository is 195 initialized, but before the remote history is fetched or any 196 files checked out. The key is in the same format as expected by 197 linkgit:git-config[1] (e.g., `core.eol=true`). If multiple 198 values are given for the same key, each value will be written to 199 the config file. This makes it safe, for example, to add 200 additional fetch refspecs to the origin remote. 201+ 202Due to limitations of the current implementation, some configuration 203variables do not take effect until after the initial fetch and checkout. 204Configuration variables known to not take effect are: 205`remote.<name>.mirror` and `remote.<name>.tagOpt`. Use the 206corresponding `--mirror` and `--no-tags` options instead. 207 208--depth <depth>:: 209 Create a 'shallow' clone with a history truncated to the 210 specified number of commits. Implies `--single-branch` unless 211 `--no-single-branch` is given to fetch the histories near the 212 tips of all branches. If you want to clone submodules shallowly, 213 also pass `--shallow-submodules`. 214 215--shallow-since=<date>:: 216 Create a shallow clone with a history after the specified time. 217 218--shallow-exclude=<revision>:: 219 Create a shallow clone with a history, excluding commits 220 reachable from a specified remote branch or tag. This option 221 can be specified multiple times. 222 223--[no-]single-branch:: 224 Clone only the history leading to the tip of a single branch, 225 either specified by the `--branch` option or the primary 226 branch remote's `HEAD` points at. 227 Further fetches into the resulting repository will only update the 228 remote-tracking branch for the branch this option was used for the 229 initial cloning. If the HEAD at the remote did not point at any 230 branch when `--single-branch` clone was made, no remote-tracking 231 branch is created. 232 233--no-tags:: 234 Don't clone any tags, and set 235 `remote.<remote>.tagOpt=--no-tags` in the config, ensuring 236 that future `git pull` and `git fetch` operations won't follow 237 any tags. Subsequent explicit tag fetches will still work, 238 (see linkgit:git-fetch[1]). 239+ 240Can be used in conjunction with `--single-branch` to clone and 241maintain a branch with no references other than a single cloned 242branch. This is useful e.g. to maintain minimal clones of the default 243branch of some repository for search indexing. 244 245--recurse-submodules[=<pathspec]:: 246 After the clone is created, initialize and clone submodules 247 within based on the provided pathspec. If no pathspec is 248 provided, all submodules are initialized and cloned. 249 This option can be given multiple times for pathspecs consisting 250 of multiple entries. The resulting clone has `submodule.active` set to 251 the provided pathspec, or "." (meaning all submodules) if no 252 pathspec is provided. 253+ 254Submodules are initialized and cloned using their default settings. This is 255equivalent to running 256`git submodule update --init --recursive <pathspec>` immediately after 257the clone is finished. This option is ignored if the cloned repository does 258not have a worktree/checkout (i.e. if any of `--no-checkout`/`-n`, `--bare`, 259or `--mirror` is given) 260 261--[no-]shallow-submodules:: 262 All submodules which are cloned will be shallow with a depth of 1. 263 264--[no-]remote-submodules:: 265 All submodules which are cloned will use the status of the submodule’s 266 remote-tracking branch to update the submodule, rather than the 267 superproject’s recorded SHA-1. Equivalent to passing `--remote` to 268 `git submodule update`. 269 270--separate-git-dir=<git dir>:: 271 Instead of placing the cloned repository where it is supposed 272 to be, place the cloned repository at the specified directory, 273 then make a filesystem-agnostic Git symbolic link to there. 274 The result is Git repository can be separated from working 275 tree. 276 277-j <n>:: 278--jobs <n>:: 279 The number of submodules fetched at the same time. 280 Defaults to the `submodule.fetchJobs` option. 281 282<repository>:: 283 The (possibly remote) repository to clone from. See the 284 <<URLS,GIT URLS>> section below for more information on specifying 285 repositories. 286 287<directory>:: 288 The name of a new directory to clone into. The "humanish" 289 part of the source repository is used if no directory is 290 explicitly given (`repo` for `/path/to/repo.git` and `foo` 291 for `host.xz:foo/.git`). Cloning into an existing directory 292 is only allowed if the directory is empty. 293 294:git-clone: 1 295include::urls.txt[] 296 297EXAMPLES 298-------- 299 300* Clone from upstream: 301+ 302------------ 303$ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux 304$ cd my-linux 305$ make 306------------ 307 308 309* Make a local clone that borrows from the current directory, without checking things out: 310+ 311------------ 312$ git clone -l -s -n . ../copy 313$ cd ../copy 314$ git show-branch 315------------ 316 317 318* Clone from upstream while borrowing from an existing local directory: 319+ 320------------ 321$ git clone --reference /git/linux.git \ 322 git://git.kernel.org/pub/scm/.../linux.git \ 323 my-linux 324$ cd my-linux 325------------ 326 327 328* Create a bare repository to publish your changes to the public: 329+ 330------------ 331$ git clone --bare -l /home/proj/.git /pub/scm/proj.git 332------------ 333 334 335GIT 336--- 337Part of the linkgit:git[1] suite