git/Documentation/git-clone.txt, branch v1.8.2.2

Documentation: the name of the system is 'Git', not 'git'

2013-02-01T21:53:33Z

Signed-off-by: Thomas Ackermann Signed-off-by: Junio C Hamano

Documentation: avoid poor-man's small caps GIT

2013-02-01T21:53:25Z

In the earlier days, we used to spell the name of the system as GIT, to simulate as if it were typeset with capital G and IT in small caps. Later we stopped doing so at around 1.6.5 days. Let's stop doing so throughout the documentation. The name to refer to the whole system (and the concept it embodies) is "Git"; the command end-users type is "git". And document this in the coding guideline. Signed-off-by: Thomas Ackermann Signed-off-by: Junio C Hamano

Documentation: remote tracking branch -> remote-tracking branch

2012-10-25T10:55:46Z

This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2 2010, Replace "remote tracking" with "remote-tracking"), but new instances of remote tracking (without dash) were introduced in the meantime. Signed-off-by: Matthieu Moy Signed-off-by: Jeff King

Merge branch 'rt/maint-clone-single' into maint

2012-10-08T18:34:02Z

A repository created with "git clone --single" had its fetch refspecs set up just like a clone without "--single", leading the subsequent "git fetch" to slurp all the other branches, defeating the whole point of specifying "only this branch". * rt/maint-clone-single: clone --single: limit the fetch refspec to fetched branch

clone --single: limit the fetch refspec to fetched branch

2012-09-20T21:15:35Z

After running "git clone --single", the resulting repository has the usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch refspec installed, which means that a subsequent "git fetch" will end up grabbing all the other branches. Update the fetch refspec to cover only the singly cloned ref instead to correct this. That means: If "--single" is used without "--branch" or "--mirror", the fetch refspec covers the branch on which remote's HEAD points to. If "--single" is used with "--branch", it'll cover only the branch specified in the "--branch" option. If "--single" is combined with "--mirror", then it'll cover all refs of the cloned repository. If "--single" is used with "--branch" that specifies a tag, then it'll cover only the ref for this tag. Signed-off-by: Ralf Thielow Signed-off-by: Junio C Hamano

clone: allow --no-local to turn off local optimizations

2012-05-30T16:51:22Z

This is basically the same as using "file://", but is a little less subtle for the end user. It also allows relative paths to be specified. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

docs/clone: mention that --local may be ignored

2012-05-30T16:51:14Z

The --local flag is not "treat this like a local repository", but rather "if we are local, turn on optimizations". Therefore it does nothing in the case of: git clone --local file:///path/to/repo Let's make that more clear in the documentation. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

clone: allow --branch to take a tag

2012-01-17T00:26:26Z

Because a tag ref cannot be put to HEAD, HEAD will become detached. This is consistent with "git checkout ". This is mostly useful in shallow clone, where it allows you to clone a tag in addtion to branches. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

clone: add --single-branch to fetch only one branch

2012-01-08T21:48:27Z

When --single-branch is given, only one branch, either HEAD or one specified by --branch, will be fetched. Also only tags that point to the downloaded history are fetched. This helps most in shallow clones, where it can reduce the download to minimum and that is why it is enabled by default when --depth is given. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

clone: accept config options on the command line

2011-06-22T18:25:21Z

Clone does all of init, "remote add", fetch, and checkout without giving the user a chance to intervene and set any configuration. This patch allows you to set config options in the newly created repository after the clone, but before we do any other operations. In many cases, this is a minor convenience over something like: git clone git://... git config core.whatever true But in some cases, it can bring extra efficiency by changing how the fetch or checkout work. For example, setting line-ending config before the checkout avoids having to re-checkout all of the contents with the correct line endings. It also provides a mechanism for passing information to remote helpers during a clone; the helpers may read the git config to influence how they operate. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano