A fast-forward is a special type of <<def_merge,merge>> where you have a
<<def_revision,revision>> and you are "merging" another
<<def_branch,branch>>'s changes that happen to be a descendant of what
- you have. In such these cases, you do not make a new <<def_merge,merge>>
+ you have. In such a case, you do not make a new <<def_merge,merge>>
<<def_commit,commit>> but instead just update to his
revision. This will happen frequently on a
<<def_remote_tracking_branch,remote-tracking branch>> of a remote
signature" letters (which optionally is terminated by another colon `:`),
and the remainder is the pattern to match against the path.
The "magic signature" consists of ASCII symbols that are neither
-alphanumeric, glob, regex special charaters nor colon.
+alphanumeric, glob, regex special characters nor colon.
The optional colon that terminates the "magic signature" can be
omitted if the pattern begins with a character that does not belong to
"magic signature" symbol set and is not a colon.
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>> and any refs
+ that start with `refs/bisect/`, 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].
<<def_push,push>> to describe the mapping between remote
<<def_ref,ref>> and local ref.
+[[def_remote]]remote repository::
+ A <<def_repository,repository>> which is used to track the same
+ project but resides somewhere else. To communicate with remotes,
+ see <<def_fetch,fetch>> or <<def_push,push>>.
+
[[def_remote_tracking_branch]]remote-tracking branch::
A <<def_ref,ref>> that is used to follow changes from another
<<def_repository,repository>>. It typically looks like
is created by giving the `--depth` option to linkgit:git-clone[1], and
its history can be later deepened with linkgit:git-fetch[1].
+[[def_submodule]]submodule::
+ A <<def_repository,repository>> that holds the history of a
+ separate project inside another repository (the latter of
+ which is called <<def_superproject, superproject>>).
+
+[[def_superproject]]superproject::
+ A <<def_repository,repository>> that references repositories
+ of other projects in its working tree as <<def_submodule,submodules>>.
+ The superproject knows about the names of (but does not hold
+ copies of) commit objects of the contained submodules.
+
[[def_symref]]symref::
Symbolic reference: instead of containing the <<def_SHA1,SHA-1>>
id itself, it is of the format 'ref: refs/some/thing' and when