docs: describe impact of repack on "clone -s"
The effects of repacking on a repository with alternates are a bit subtle. The two main things users will want are: 1. Not to waste disk space by accidentally copying objects which could be shared. 2. Copying all objects explicitly to break the dependency on the source repo. This patch describes both under the "clone -s" documentation. It makes sense to put it there rather than in git-repack.txt for both cases. For (1), we are warning the user who is using "clone -s" about what _not_ to do, so we need to get their attention when reading about "clone -s". For (2), we are telling them how git-repack can be used to accomplish a task, but until they know that git-repack is the right tool, they have no reason to look at the repack documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
2cd9c2aff0
commit
13354f5377
@ -72,8 +72,16 @@ These objects may be removed by normal git operations (such as 'git-commit')
|
||||
which automatically call `git gc --auto`. (See linkgit: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.
|
||||
|
||||
--reference <repository>::
|
||||
If the reference repository is on the local machine
|
||||
|
Loading…
Reference in New Issue
Block a user