-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Provide some technical documentation for shallow clones
There has not been any work on the shallow stuff lately, so it is hard to find out what it does, and how. This document describes the ideas as well as the current problems, and can serve as a starting point for shallow people. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
- Loading branch information
Johannes Schindelin
authored and
Junio C Hamano
committed
Mar 20, 2007
1 parent
e29b96d
commit 1b89ef1
Showing
1 changed file
with
49 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
Def.: Shallow commits do have parents, but not in the shallow | ||
repo, and therefore grafts are introduced pretending that | ||
these commits have no parents. | ||
|
||
The basic idea is to write the SHA1s of shallow commits into | ||
$GIT_DIR/shallow, and handle its contents like the contents | ||
of $GIT_DIR/info/grafts (with the difference that shallow | ||
cannot contain parent information). | ||
|
||
This information is stored in a new file instead of grafts, or | ||
even the config, since the user should not touch that file | ||
at all (even throughout development of the shallow clone, it | ||
was never manually edited!). | ||
|
||
Each line contains exactly one SHA1. When read, a commit_graft | ||
will be constructed, which has nr_parent < 0 to make it easier | ||
to discern from user provided grafts. | ||
|
||
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. |