git/Documentation/git-clone.txt, branch v2.7.2

Merge branch 'ss/clone-depth-single-doc' into maint

2016-02-05T22:54:22Z

Documentation for "git fetch --depth" has been updated for clarity. * ss/clone-depth-single-doc: docs: clarify that --depth for git-fetch works with newly initialized repos docs: say "commits" in the --depth option wording for git-clone docs: clarify that passing --depth to git-clone implies --single-branch

docs: say "commits" in the --depth option wording for git-clone

2016-01-08T20:39:58Z

It is not wrong to talk about "revisions" here, but in this context revisions are always commits, and that is how we already name it in the git-fetch docs. So align the docs by always referring to "commits". Signed-off-by: Junio C Hamano

docs: clarify that passing --depth to git-clone implies --single-branch

2016-01-07T19:45:19Z

It is confusing to document how --depth behaves as part of the --single-branch docs. Better move that part to the --depth docs, saying that it implies --single-branch by default. Signed-off-by: Sebastian Schuberth Signed-off-by: Junio C Hamano

clone: allow "--dissociate" without reference

2015-10-22T19:13:29Z

The "--reference" option is not the only way to provide a repository to borrow objects from. A repository that borrows from another repository can be cloned with "clone --local" and the resulting repository will borrow from the same repository, which the user may want to "--dissociate" from. Signed-off-by: Alex Riesen Signed-off-by: Junio C Hamano

clone: --dissociate option to mark that reference is only temporary

2014-10-15T21:34:45Z

While use of the --reference option to borrow objects from an existing local repository of the same project is an effective way to reduce traffic when cloning a project over the network, it makes the resulting "borrowing" repository dependent on the "borrowed" repository. After running git clone --reference=P $URL Q the resulting repository Q will be broken if the borrowed repository P disappears. The way to allow the borrowed repository to be removed is to repack the borrowing repository (i.e. run "git repack -a -d" in Q); while power users may know it very well, it is not easily discoverable. Teach a new "--dissociate" option to "git clone" to run this repacking for the user. Helped-by: Johannes Sixt Signed-off-by: Junio C Hamano

docs/git-clone: clarify use of --no-hardlinks option

2014-02-11T19:03:07Z

Current text claims optimization, implying the use of hardlinks, when this option ratchets down the level of efficiency. This change explains the difference made by using this option, namely copying instead of hardlinking, and why it may be useful. Signed-off-by: Albert L. Lash, IV Signed-off-by: Junio C Hamano

Merge branch 'ow/manpages-typofix'

2014-02-07T19:55:12Z

Various typofixes, all looked correct. * ow/manpages-typofix: Documentation: fix typos in man pages

Documentation: fix typos in man pages

2014-02-05T22:35:45Z

Signed-off-by: Øystein Walle Signed-off-by: Junio C Hamano

git-clone.txt: remove shallow clone limitations

2013-12-11T00:14:19Z

Now that git supports data transfer from or to a shallow clone, these limitations are not true anymore. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Revert "git-clone.txt: remove the restriction on pushing from a shallow clone"

2013-07-15T15:35:32Z

This reverts commit dacd2bcc414e0b7aac36aaa400da0a743c4741cc. "It fails reliably without corrupting the receiving repository when it should fail" may be better than the situation before the receiving end was hardened recently, but the fact that sometimes the push does not go through still remains. It is better to advice the users that they cannot push from a shallow repository as a limitation before they decide to use (or not to use) a shallow clone. Signed-off-by: Junio C Hamano