1f010d6bdf
We presently use the ".txt" extension for our AsciiDoc files. While not wrong, most editors do not associate this extension with AsciiDoc, meaning that contributors don't get automatic editor functionality that could be useful, such as syntax highlighting and prose linting. It is much more common to use the ".adoc" extension for AsciiDoc files, since this helps editors automatically detect files and also allows various forges to provide rich (HTML-like) rendering. Let's do that here, renaming all of the files and updating the includes where relevant. Adjust the various build scripts and makefiles to use the new extension as well. Note that this should not result in any user-visible changes to the documentation. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
61 lines
2.5 KiB
Plaintext
61 lines
2.5 KiB
Plaintext
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.
|