Home Explore Blog CI



git

4th chunk of `Documentation/git-clone.adoc`
baf9c5241a4bf331d4f147c6b39a418d007ddf6b995816020000000100000e0c
 _<name>_ branch
	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.

`--revision=<rev>`::
	Create a new repository, and fetch the history leading to the given
	revision _<rev>_ (and nothing else), without making any remote-tracking
	branch, and without making any local branch, and detach `HEAD` to
	_<rev>_. The argument can be a ref name (e.g. `refs/heads/main` or
	`refs/tags/v1.0`) that peels down to a commit, or a hexadecimal object
	name.
	This option is incompatible with `--branch` and `--mirror`.

`-u` _<upload-pack>_::
`--upload-pack` _<upload-pack>_::
	When given, and the repository to clone from is accessed
	via ssh, this specifies a non-default path for the command
	run on the other end.

`--template=<template-directory>`::
	Specify the directory from which templates will be used;
	(See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].)

`-c` `<key>=<value>`::
`--config` `<key>=<value>`::
	Set a configuration variable in the newly-created repository;
	this takes effect immediately after the repository is
	initialized, but before the remote history is fetched or any
	files checked out.  The _<key>_ is in the same format as expected by
	linkgit:git-config[1] (e.g., `core.eol=true`). If multiple
	values are given for the same key, each value will be written to
	the config file. This makes it safe, for example, to add
	additional fetch refspecs to the origin remote.
+
Due to limitations of the current implementation, some configuration
variables do not take effect until after the initial fetch and checkout.
Configuration variables known to not take effect are:
`remote.<name>.mirror` and `remote.<name>.tagOpt`.  Use the
corresponding `--mirror` and `--no-tags` options instead.

`--depth <depth>`::
	Create a 'shallow' clone with a history truncated to the
	specified number of commits. Implies `--single-branch` unless
	`--no-single-branch` is given to fetch the histories near the
	tips of all branches. If you want to clone submodules shallowly,
	also pass `--shallow-submodules`.

`--shallow-since=<date>`::
	Create a shallow clone with a history after the specified time.

`--shallow-exclude=<ref>`::
	Create a shallow clone with a history, excluding commits
	reachable from a specified remote branch or tag.  This option
	can be specified multiple times.

`--[no-]single-branch`::
	Clone only the history leading to the tip of a single branch,
	either specified by the `--branch` option or the primary
	branch remote's `HEAD` points at.
	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.

`--[no-]tags`::
	Control whether or not tags will be cloned. When `--no-tags` is
	given, the option will be become permanent by setting the
	`remote.<remote>.tagOpt=--no-tags` configuration. This ensures that
	future `git pull` and `git fetch` won't follow any tags. Subsequent
	explicit tag fetches will still work (see linkgit:git-fetch[1]).
+
By default, tags are cloned and passing `--tags` is thus typically a
no-op, unless it cancels out a previous `--no-tags`.
+
Can be used in conjunction with `--single-branch` to clone and
maintain a branch with no references other than a single cloned
branch. This is useful e.g. to maintain minimal clones of the default
branch of some repository

Title: Git Clone Configuration and Shallow Cloning Options
Summary
The git clone command provides various options to configure the cloning process, including setting configuration variables, shallow cloning, and controlling the cloning of branches and tags, allowing for customized and efficient repository creation.