]> git.ipfire.org Git - thirdparty/git.git/blob - Documentation/git-clone.txt
path.c: clarify trie_find()'s in-code comment
[thirdparty/git.git] / Documentation / git-clone.txt
1 git-clone(1)
2 ============
3
4 NAME
5 ----
6 git-clone - Clone a repository into a new directory
7
8
9 SYNOPSIS
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
21 DESCRIPTION
22 -----------
23
24 Clones a repository into a newly created directory, creates
25 remote-tracking branches for each branch in the cloned repository
26 (visible using `git branch --remotes`), and creates and checks out an
27 initial branch that is forked from the cloned repository's
28 currently active branch.
29
30 After the clone, a plain `git fetch` without arguments will update
31 all the remote-tracking branches, and a `git pull` without
32 arguments will in addition merge the remote master branch into the
33 current master branch, if any (this is untrue when "--single-branch"
34 is given; see below).
35
36 This default configuration is achieved by creating references to
37 the remote branch heads under `refs/remotes/origin` and
38 by initializing `remote.origin.url` and `remote.origin.fetch`
39 configuration variables.
40
41
42 OPTIONS
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 +
53 If the repository is specified as a local path (e.g., `/path/to/repo`),
54 this is the default, and --local is essentially a no-op. If the
55 repository is specified as a URL, then this flag is ignored (and we
56 never use the local optimizations). Specifying `--no-local` will
57 override the default when `/path/to/repo` is given, using the regular
58 Git 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
75 it unless you understand what it does. If you clone your
76 repository using this option and then delete branches (or use any
77 other Git command that makes any existing commit unreferenced) in the
78 source repository, some objects may become unreferenced (or dangling).
79 These objects may be removed by normal Git operations (such as `git commit`)
80 which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
81 If these objects are removed and were referenced by the cloned repository,
82 then the cloned repository will become corrupt.
83 +
84 Note that running `git repack` without the `--local` option in a repository
85 cloned with `--shared` will copy objects from the source repository into a pack
86 in the cloned repository, removing the disk space savings of `clone --shared`.
87 It is safe, however, to run `git gc`, which uses the `--local` option by
88 default.
89 +
90 If you want to break the dependency of a repository cloned with `--shared` on
91 its source repository, you can simply run `git repack -a` to copy all
92 objects 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 +
202 Due to limitations of the current implementation, some configuration
203 variables do not take effect until after the initial fetch and checkout.
204 Configuration variables known to not take effect are:
205 `remote.<name>.mirror` and `remote.<name>.tagOpt`. Use the
206 corresponding `--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 +
240 Can be used in conjunction with `--single-branch` to clone and
241 maintain a branch with no references other than a single cloned
242 branch. This is useful e.g. to maintain minimal clones of the default
243 branch 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 +
254 Submodules are initialized and cloned using their default settings. This is
255 equivalent to running
256 `git submodule update --init --recursive <pathspec>` immediately after
257 the clone is finished. This option is ignored if the cloned repository does
258 not have a worktree/checkout (i.e. if any of `--no-checkout`/`-n`, `--bare`,
259 or `--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
295 include::urls.txt[]
296
297 EXAMPLES
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
335 GIT
336 ---
337 Part of the linkgit:git[1] suite