[thirdparty/git.git] / Documentation / config / checkout.txt

checkout.defaultRemote::
	When you run `git checkout <something>`
	or `git switch <something>` and only have one
	remote, it may implicitly fall back on checking out and
	tracking e.g. `origin/<something>`. This stops working as soon
	as you have more than one remote with a `<something>`
	reference. This setting allows for setting the name of a
	preferred remote that should always win when it comes to
	disambiguation. The typical use-case is to set this to
	`origin`.
+
Currently this is used by linkgit:git-switch[1] and
linkgit:git-checkout[1] when `git checkout <something>`
or `git switch <something>`
will checkout the `<something>` branch on another remote,
and by linkgit:git-worktree[1] when `git worktree add` refers to a
remote branch. This setting might be used for other checkout-like
commands or functionality in the future.

checkout.guess::
	Provides the default value for the `--guess` or `--no-guess`
	option in `git checkout` and `git switch`. See
	linkgit:git-switch[1] and linkgit:git-checkout[1].

checkout.workers::
	The number of parallel workers to use when updating the working tree.
	The default is one, i.e. sequential execution. If set to a value less
	than one, Git will use as many workers as the number of logical cores
	available. This setting and `checkout.thresholdForParallelism` affect
	all commands that perform checkout. E.g. checkout, clone, reset,
	sparse-checkout, etc.
+
Note: Parallel checkout usually delivers better performance for repositories
located on SSDs or over NFS. For repositories on spinning disks and/or machines
with a small number of cores, the default sequential checkout often performs
better. The size and compression level of a repository might also influence how
well the parallel version performs.

checkout.thresholdForParallelism::
	When running parallel checkout with a small number of files, the cost
	of subprocess spawning and inter-process communication might outweigh
	the parallelization gains. This setting allows you to define the minimum
	number of files for which parallel checkout should be attempted. The
	default is 100.
Commit	Line	Data
9140b410	1	checkout.defaultRemote::
ef09e7dd DL	2	When you run `git checkout <something>`
ef09e7dd DL	3	or `git switch <something>` and only have one
9140b410	4	remote, it may implicitly fall back on checking out and
ef09e7dd DL	5	tracking e.g. `origin/<something>`. This stops working as soon
ef09e7dd DL	6	as you have more than one remote with a `<something>`
9140b410 NTND	7	reference. This setting allows for setting the name of a
	8	preferred remote that should always win when it comes to
	9	disambiguation. The typical use-case is to set this to
	10	`origin`.
	11	+
d787d311	12	Currently this is used by linkgit:git-switch[1] and
ef09e7dd DL	13	linkgit:git-checkout[1] when `git checkout <something>`
	14	or `git switch <something>`
	15	will checkout the `<something>` branch on another remote,
	16	and by linkgit:git-worktree[1] when `git worktree add` refers to a
9140b410 NTND	17	remote branch. This setting might be used for other checkout-like
9140b410 NTND	18	commands or functionality in the future.
64f1f58f DL	19
	20	checkout.guess::
	21	Provides the default value for the `--guess` or `--no-guess`
	22	option in `git checkout` and `git switch`. See
	23	linkgit:git-switch[1] and linkgit:git-checkout[1].
7531e4b6 MT	24
	25	checkout.workers::
	26	The number of parallel workers to use when updating the working tree.
	27	The default is one, i.e. sequential execution. If set to a value less
	28	than one, Git will use as many workers as the number of logical cores
	29	available. This setting and `checkout.thresholdForParallelism` affect
	30	all commands that perform checkout. E.g. checkout, clone, reset,
	31	sparse-checkout, etc.
	32	+
2150b6fb	33	Note: Parallel checkout usually delivers better performance for repositories
7531e4b6 MT	34	located on SSDs or over NFS. For repositories on spinning disks and/or machines
	35	with a small number of cores, the default sequential checkout often performs
	36	better. The size and compression level of a repository might also influence how
	37	well the parallel version performs.
	38
	39	checkout.thresholdForParallelism::
	40	When running parallel checkout with a small number of files, the cost
	41	of subprocess spawning and inter-process communication might outweigh
89363522	42	the parallelization gains. This setting allows you to define the minimum
7531e4b6 MT	43	number of files for which parallel checkout should be attempted. The
7531e4b6 MT	44	default is 100.