about summary refs log tree commit diff
path: root/third_party/git/Documentation/technical/shallow.txt
diff options
context:
space:
mode:
Diffstat (limited to 'third_party/git/Documentation/technical/shallow.txt')
-rw-r--r--third_party/git/Documentation/technical/shallow.txt60
1 files changed, 0 insertions, 60 deletions
diff --git a/third_party/git/Documentation/technical/shallow.txt b/third_party/git/Documentation/technical/shallow.txt
deleted file mode 100644
index f3738baa0f05..000000000000
--- a/third_party/git/Documentation/technical/shallow.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-Shallow commits
-===============
-
-.Definition
-*********************************************************
-Shallow commits do have parents, but not in the shallow
-repo, and therefore grafts are introduced pretending that
-these commits have no parents.
-*********************************************************
-
-$GIT_DIR/shallow lists commit object names and tells Git to
-pretend as if they are root commits (e.g. "git log" traversal
-stops after showing them; "git fsck" does not complain saying
-the commits listed on their "parent" lines do not exist).
-
-Each line contains exactly one object name. When read, a commit_graft
-will be constructed, which has nr_parent < 0 to make it easier
-to discern from user provided grafts.
-
-Note that the shallow feature could not be changed easily to
-use replace refs: a commit containing a `mergetag` is not allowed
-to be replaced, not even by a root commit. Such a commit can be
-made shallow, though. Also, having a `shallow` file explicitly
-listing all the commits made shallow makes it a *lot* easier to
-do shallow-specific things such as to deepen the history.
-
-Since fsck-objects relies on the library to read the objects,
-it honours shallow commits automatically.
-
-There are some unfinished ends of the whole shallow business:
-
-- maybe we have to force non-thin packs when fetching into a
-  shallow repo (ATM they are forced non-thin).
-
-- A special handling of a shallow upstream is needed. At some
-  stage, upload-pack has to check if it sends a shallow commit,
-  and it should send that information early (or fail, if the
-  client does not support shallow repositories). There is no
-  support at all for this in this patch series.
-
-- Instead of locking $GIT_DIR/shallow at the start, just
-  the timestamp of it is noted, and when it comes to writing it,
-  a check is performed if the mtime is still the same, dying if
-  it is not.
-
-- It is unclear how "push into/from a shallow repo" should behave.
-
-- If you deepen a history, you'd want to get the tags of the
-  newly stored (but older!) commits. This does not work right now.
-
-To make a shallow clone, you can call "git-clone --depth 20 repo".
-The result contains only commit chains with a length of at most 20.
-It also writes an appropriate $GIT_DIR/shallow.
-
-You can deepen a shallow repository with "git-fetch --depth 20
-repo branch", which will fetch branch from repo, but stop at depth
-20, updating $GIT_DIR/shallow.
-
-The special depth 2147483647 (or 0x7fffffff, the largest positive
-number a signed 32-bit integer can contain) means infinite depth.