diff options
Diffstat (limited to 'third_party/git/Documentation/technical/shallow.txt')
| -rw-r--r-- | third_party/git/Documentation/technical/shallow.txt | 60 |
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 01dedfe9ff..0000000000 --- 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 SHA-1. 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. |