[PATCH v5 1/5] refs: introduce pseudoref and per-worktree ref concepts
- From
David Turner <dturner@twopensource.com>
- Date
- Jul 31, 2015, 06:06 UTC
- Message-ID
- <1438322781-21181-1-git-send-email-dturner@twopensource.com>
Add glossary entries for both concepts.
Pseudorefs and per-worktree refs do not yet have special handling, because the files refs backend already handles them correctly. Later, we will make the LMDB backend call out to the files backend to handle per-worktree refs.
Signed-off-by: David Turner <dturner@twopensource.com> ---
This version squashes in Junio's glossary and capitalization corrections, and corrects the spelling of pseudoref (thanks to Johan Herland).
---
Documentation/glossary-content.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index ab18f4b..8c6478b 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -411,6 +411,27 @@ exclude;; core Git. Porcelains expose more of a <<def_SCM,SCM>> interface than the <<def_plumbing,plumbing>>. +[[def_per_worktree_ref]]per-worktree ref:: + Refs that are per-<<def_working_tree,worktree>>, rather than + global. This is presently only <<def_HEAD,HEAD>>, but might + later include other unusual refs. + +[[def_pseudoref]]pseudoref:: + Pseudorefs are a class of files under `$GIT_DIR` which behave + like refs for the purposes of rev-parse, but which are treated + specially by git. Pseudorefs both have names that are all-caps, + and always start with a line consisting of a + <<def_SHA1,SHA-1>> followed by whitespace. So, HEAD is not a + pseudoref, because it is sometimes a symbolic ref. They might + optionally contain some additional data. `MERGE_HEAD` and + `CHERRY_PICK_HEAD` are examples. Unlike + <<def_per_worktree_ref,per-worktree refs>>, these files cannot + be symbolic refs, and never have reflogs. They also cannot be + updated through the normal ref update machinery. Instead, + they are updated by directly writing to the files. However, + they can be read as if they were refs, so `git rev-parse + MERGE_HEAD` will work. + [[def_pull]]pull:: Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and <<def_merge,merge>> it. See also linkgit:git-pull[1].
-- 2.0.4.315.gad8727a-twtrsrc