After the clone, a plain `git fetch` without arguments will update
all the remote-tracking branches, and a `git pull` without
arguments will in addition merge the remote master branch into the
-current master branch, if any.
+current master branch, if any (this is untrue when "--single-branch"
+is given; see below).
This default configuration is achieved by creating references to
the remote branch heads under `refs/remotes/origin` and
--local::
-l::
When the repository to clone from is on a local machine,
- this flag bypasses the normal "git aware" transport
+ this flag bypasses the normal "Git aware" transport
mechanism and clones the repository by making a copy of
HEAD and everything under objects and refs directories.
The files under `.git/objects/` directory are hardlinked
repository is specified as a URL, then this flag is ignored (and we
never use the local optimizations). Specifying `--no-local` will
override the default when `/path/to/repo` is given, using the regular
-git transport instead.
+Git transport instead.
+
To force copying instead of hardlinking (which may be desirable if you
are trying to make a back-up of your repository), but still avoid the
-usual "git aware" transport mechanism, `--no-hardlinks` can be used.
+usual "Git aware" transport mechanism, `--no-hardlinks` can be used.
--no-hardlinks::
Optimize the cloning process from a repository on a
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand what it does. If you clone your
repository using this option and then delete branches (or use any
-other git command that makes any existing commit unreferenced) in the
+other Git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
-These objects may be removed by normal git operations (such as `git commit`)
+These objects may be removed by normal Git operations (such as `git commit`)
which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
If these objects are removed and were referenced by the cloned repository,
then the cloned repository will become corrupt.
No checkout of HEAD is performed after the clone is complete.
--bare::
- Make a 'bare' GIT repository. That is, instead of
+ Make a 'bare' Git repository. That is, instead of
creating `<directory>` and placing the administrative
files in `<directory>/.git`, make the `<directory>`
itself the `$GIT_DIR`. This obviously implies the `-n`
-b <name>::
Instead of pointing the newly created HEAD to the branch pointed
to by the cloned repository's HEAD, point to `<name>` branch
- instead. `--branch` can also take tags and treat them like
- detached HEAD. In a non-bare repository, this is the branch
- that will be checked out.
+ instead. In a non-bare repository, this is the branch that will
+ be checked out.
+ `--branch` can also take tags and detaches the HEAD at that commit
+ in the resulting repository.
--upload-pack <upload-pack>::
-u <upload-pack>::
clone with the `--depth` option, this is the default, unless
`--no-single-branch` is given to fetch the histories near the
tips of all branches.
+ Further fetches into the resulting repository will only update the
+ remote-tracking branch for the branch this option was used for the
+ initial cloning. If the HEAD at the remote did not point at any
+ branch when `--single-branch` clone was made, no remote-tracking
+ branch is created.
--recursive::
--recurse-submodules::
--separate-git-dir=<git dir>::
Instead of placing the cloned repository where it is supposed
to be, place the cloned repository at the specified directory,
- then make a filesytem-agnostic git symbolic link to there.
- The result is git repository can be separated from working
+ then make a filesytem-agnostic Git symbolic link to there.
+ The result is Git repository can be separated from working
tree.