61 lines
2.5 KiB
Text
61 lines
2.5 KiB
Text
|
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.
|