The original wording sounded as if --depth could only be used to deepen or
shorten the history of existing repos. However, that is not the case. In a
workflow like
$ git init
$ git remote add origin https://github.com/git/git.git
$ git fetch --depth=1
The newly initialized repo is properly created as a shallow repo.
---
Documentation/fetch-options.txt | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 45583d8..78cd265 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -8,10 +8,11 @@
option old data in `.git/FETCH_HEAD` will be overwritten.
--depth=<depth>::
- Deepen or shorten the history of a 'shallow' repository created by
- `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
- to the specified number of commits from the tip of each remote
- branch history. Tags for the deepened commits are not fetched.
+ Limit fetching to the specified number of commits from the tip of
+ each remote branch history. If fetching to a 'shallow' repository
+ created by `git clone` with `--depth=<depth>` option (see
+ linkgit:git-clone[1]), deepen or shorten the history to the specified
+ number of commits. Tags for the deepened commits are not fetched.
--unshallow::
If the source repository is complete, convert a shallow
--
2.7.0.windows.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html