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

Merge branch 'jk/drop-rsync-transport'

2016-02-17T18:13:28Z

It turns out "git clone" over rsync transport has been broken when the source repository has packed references for a long time, and nobody noticed nor complained about it. * jk/drop-rsync-transport: transport: drop support for git-over-rsync

transport: drop support for git-over-rsync

2016-02-01T21:07:41Z

The git-over-rsync protocol is inefficient and broken, and has been for a long time. It transfers way more objects than it needs (grabbing all of the remote's "objects/", regardless of which objects we need). It does its own ad-hoc parsing of loose and packed refs from the remote, but doesn't properly override packed refs with loose ones, leading to garbage results (e.g., expecting the other side to have an object pointed to by a stale packed-refs entry, or complaining that the other side has two copies of the refs[1]). This latter breakage means that nobody could have successfully pulled from a moderately active repository since cd547b4 (fetch/push: readd rsync support, 2007-10-01). We never made an official deprecation notice in the release notes for git's rsync protocol, but the tutorial has marked it as such since 914328a (Update tutorial., 2005-08-30). And on the mailing list as far back as Oct 2005, we can find Junio mentioning it as having "been deprecated for quite some time."[2,3,4]. So it was old news then; cogito had deprecated the transport in July of 2005[5] (though it did come back briefly when Linus broke git-http-pull!). Of course some people professed their love of rsync through 2006, but Linus clarified in his usual gentle manner[6]: > Thanks! This is why I still use rsync, even though > everybody and their mother tells me "Linus says rsync is > deprecated." No. You're using rsync because you're actively doing something _wrong_. The deprecation sentiment was reinforced in 2008, with a mention that cloning via rsync is broken (with no fix)[7]. Even the commit porting rsync over to C from shell (cd547b4) lists it as deprecated! So between the 10 years of informal warnings, and the fact that it has been severely broken since 2007, it's probably safe to simply remove it without further deprecation warnings. [1] http://article.gmane.org/gmane.comp.version-control.git/285101 [2] http://article.gmane.org/gmane.comp.version-control.git/10093 [3] http://article.gmane.org/gmane.comp.version-control.git/17734 [4] http://article.gmane.org/gmane.comp.version-control.git/18911 [5] http://article.gmane.org/gmane.comp.version-control.git/5617 [6] http://article.gmane.org/gmane.comp.version-control.git/19354 [7] http://article.gmane.org/gmane.comp.version-control.git/103635 Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

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

2016-01-20T19:43:35Z

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