git clone -s详解

从远程主机复制仓库到本地主机最常用的方式就是

git clone <repo> [<path>]

但"git clone"的用途不知局限于此。git-clone也可实现本地主机上的仓库复制，这时一般使用

git clone -s <path to source repo> [<directory>]

下面解释一下这个命令。

当<path to source repo>为本地路径而非URL时，Git会启动本地优化，即 -l 标志将会启动。

当 -l 标志启动时，如果 -s 标志也启动，Git 将会自动启动 alternates 机制，建立 .git/objects/info/alternates 来实现与源仓库共享 objects。Git 的文档中也提醒这是个危险的操作。原文如此：

NOTE: this is a possibly dangerous operation; do not use it unless you understand what it does. If you clone your repository using this option and then delete branches (or use any other Git command that makes any existing commit unreferenced) in the source repository, some objects may become unreferenced (or dangling). These objects may be removed by normal Git operations (such as git commit) which automatically call git gc --auto. (See git-gc(1).) If these objects are removed and were referenced by the cloned repository, then the cloned repository will become corrupt.

Note that running git repack without the -l option in a repository cloned with -s will copy objects from the source repository into a pack in the cloned repository, removing the disk space savings of clone -s. It is safe, however, to run git gc, which uses the -l option by default.

If you want to break the dependency of a repository cloned with -s on its source repository, you can simply run git repack -a to copy all objects from the source repository into a pack in the cloned repository.

翻译一下：

注意：这可能是个危险的操作；不要使用除非你知道是怎么回事儿。如果你使用这个操作复制了你的仓库，然后在源仓库删除分支（或者使用其它会使已经存在 commit 不再被引用的的 Git 命令），有的对象会成为悬空对象。这些对象会被一些常规的 Git 操作（比如"git commit"）删除，这些操作回自动调用"git gc --auto"。如果这些对象被移除了，却在从它派生的仓库中被引用，那么就出错了。
注意在用 -s 选项复制得到的仓库上运行不带 -l 选项的 "git repack" 命令会将源仓库的对象拷贝到派生仓库的一个 pack 中，这样做消除了 "clone -s" 节约的磁盘空间。这样做是安全的。但是，运行 "git gc" 命令默认会使用 -l 选项。
如果你想打破用 -s 选项复制得到的仓库对源仓库的依赖性，可以简单地运行 "git repack -a" 来从源仓库将所有对象拷贝到派生仓库的一个pack。

从上面我们可以看出 “git clone -s” 节约了磁盘空间，但加大了仓库间的依赖性及操作的复杂程度。