logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

gitglossary.7 (32480B)


  1. '\" t
  2. .\" Title: gitglossary
  3. .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
  4. .\" Generator: DocBook XSL Stylesheets v1.79.2 <http://docbook.sf.net/>
  5. .\" Date: 2025-03-14
  6. .\" Manual: Git Manual
  7. .\" Source: Git 2.49.0
  8. .\" Language: English
  9. .\"
  10. .TH "GITGLOSSARY" "7" "2025-03-14" "Git 2\&.49\&.0" "Git Manual"
  11. .\" -----------------------------------------------------------------
  12. .\" * Define some portability stuff
  13. .\" -----------------------------------------------------------------
  14. .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  15. .\" http://bugs.debian.org/507673
  16. .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
  17. .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  18. .ie \n(.g .ds Aq \(aq
  19. .el .ds Aq '
  20. .\" -----------------------------------------------------------------
  21. .\" * set default formatting
  22. .\" -----------------------------------------------------------------
  23. .\" disable hyphenation
  24. .nh
  25. .\" disable justification (adjust text to left margin only)
  26. .ad l
  27. .\" -----------------------------------------------------------------
  28. .\" * MAIN CONTENT STARTS HERE *
  29. .\" -----------------------------------------------------------------
  30. .SH "NAME"
  31. gitglossary \- A Git Glossary
  32. .SH "SYNOPSIS"
  33. .sp
  34. *
  35. .SH "DESCRIPTION"
  36. .PP
  37. alternate object database
  38. .RS 4
  39. Via the alternates mechanism, a
  40. repository
  41. can inherit part of its
  42. object database
  43. from another object database, which is called an "alternate"\&.
  44. .RE
  45. .PP
  46. bare repository
  47. .RS 4
  48. A bare repository is normally an appropriately named
  49. directory
  50. with a \&.\fBgit\fR
  51. suffix that does not have a locally checked\-out copy of any of the files under revision control\&. That is, all of the Git administrative and control files that would normally be present in the hidden \&.\fBgit\fR
  52. sub\-directory are directly present in the
  53. \fBrepository\&.git\fR
  54. directory instead, and no other files are present and checked out\&. Usually publishers of public repositories make bare repositories available\&.
  55. .RE
  56. .PP
  57. blob object
  58. .RS 4
  59. Untyped
  60. object, e\&.g\&. the contents of a file\&.
  61. .RE
  62. .PP
  63. branch
  64. .RS 4
  65. A "branch" is a line of development\&. The most recent
  66. commit
  67. on a branch is referred to as the tip of that branch\&. The tip of the branch is
  68. referenced
  69. by a branch
  70. head, which moves forward as additional development is done on the branch\&. A single Git
  71. repository
  72. can track an arbitrary number of branches, but your
  73. working tree
  74. is associated with just one of them (the "current" or "checked out" branch), and
  75. HEAD
  76. points to that branch\&.
  77. .RE
  78. .PP
  79. cache
  80. .RS 4
  81. Obsolete for:
  82. index\&.
  83. .RE
  84. .PP
  85. chain
  86. .RS 4
  87. A list of objects, where each
  88. object
  89. in the list contains a reference to its successor (for example, the successor of a
  90. commit
  91. could be one of its
  92. parents)\&.
  93. .RE
  94. .PP
  95. changeset
  96. .RS 4
  97. BitKeeper/cvsps speak for "commit"\&. Since Git does not store changes, but states, it really does not make sense to use the term "changesets" with Git\&.
  98. .RE
  99. .PP
  100. checkout
  101. .RS 4
  102. The action of updating all or part of the
  103. working tree
  104. with a
  105. tree object
  106. or
  107. blob
  108. from the
  109. object database, and updating the
  110. index
  111. and
  112. HEAD
  113. if the whole working tree has been pointed at a new
  114. branch\&.
  115. .RE
  116. .PP
  117. cherry\-picking
  118. .RS 4
  119. In
  120. SCM
  121. jargon, "cherry pick" means to choose a subset of changes out of a series of changes (typically commits) and record them as a new series of changes on top of a different codebase\&. In Git, this is performed by the "git cherry\-pick" command to extract the change introduced by an existing
  122. commit
  123. and to record it based on the tip of the current
  124. branch
  125. as a new commit\&.
  126. .RE
  127. .PP
  128. clean
  129. .RS 4
  130. A
  131. working tree
  132. is clean, if it corresponds to the
  133. revision
  134. referenced by the current
  135. head\&. Also see "dirty"\&.
  136. .RE
  137. .PP
  138. commit
  139. .RS 4
  140. As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits\&. The word "commit" is often used by Git in the same places other revision control systems use the words "revision" or "version"\&. Also used as a short hand for
  141. commit object\&.
  142. .sp
  143. As a verb: The action of storing a new snapshot of the project\(cqs state in the Git history, by creating a new commit representing the current state of the
  144. index
  145. and advancing
  146. HEAD
  147. to point at the new commit\&.
  148. .RE
  149. .PP
  150. commit graph concept, representations and usage
  151. .RS 4
  152. A synonym for the
  153. DAG
  154. structure formed by the commits in the object database,
  155. referenced
  156. by branch tips, using their
  157. chain
  158. of linked commits\&. This structure is the definitive commit graph\&. The graph can be represented in other ways, e\&.g\&. the
  159. "commit\-graph" file\&.
  160. .RE
  161. .PP
  162. commit\-graph file
  163. .RS 4
  164. The "commit\-graph" (normally hyphenated) file is a supplemental representation of the
  165. commit graph
  166. which accelerates commit graph walks\&. The "commit\-graph" file is stored either in the \&.git/objects/info directory or in the info directory of an alternate object database\&.
  167. .RE
  168. .PP
  169. commit object
  170. .RS 4
  171. An
  172. object
  173. which contains the information about a particular
  174. revision, such as
  175. parents, committer, author, date and the
  176. tree object
  177. which corresponds to the top
  178. directory
  179. of the stored revision\&.
  180. .RE
  181. .PP
  182. commit\-ish (also committish)
  183. .RS 4
  184. A
  185. commit object
  186. or an
  187. object
  188. that can be recursively
  189. dereferenced
  190. to a commit object\&. The following are all commit\-ishes: a commit object, a
  191. tag object
  192. that points to a commit object, a tag object that points to a tag object that points to a commit object, etc\&.
  193. .RE
  194. .PP
  195. core Git
  196. .RS 4
  197. Fundamental data structures and utilities of Git\&. Exposes only limited source code management tools\&.
  198. .RE
  199. .PP
  200. DAG
  201. .RS 4
  202. Directed acyclic graph\&. The
  203. commit objects
  204. form a directed acyclic graph, because they have parents (directed), and the graph of commit objects is acyclic (there is no
  205. chain
  206. which begins and ends with the same
  207. object)\&.
  208. .RE
  209. .PP
  210. dangling object
  211. .RS 4
  212. An
  213. unreachable object
  214. which is not
  215. reachable
  216. even from other unreachable objects; a dangling object has no references to it from any reference or
  217. object
  218. in the
  219. repository\&.
  220. .RE
  221. .PP
  222. dereference
  223. .RS 4
  224. Referring to a
  225. symbolic ref: the action of accessing the
  226. reference
  227. pointed at by a symbolic ref\&. Recursive dereferencing involves repeating the aforementioned process on the resulting ref until a non\-symbolic reference is found\&.
  228. .sp
  229. Referring to a
  230. tag object: the action of accessing the
  231. object
  232. a tag points at\&. Tags are recursively dereferenced by repeating the operation on the result object until the result has either a specified
  233. object type
  234. (where applicable) or any non\-"tag" object type\&. A synonym for "recursive dereference" in the context of tags is "peel"\&.
  235. .sp
  236. Referring to a
  237. commit object: the action of accessing the commit\(cqs tree object\&. Commits cannot be dereferenced recursively\&.
  238. .sp
  239. Unless otherwise specified, "dereferencing" as it used in the context of Git commands or protocols is implicitly recursive\&.
  240. .RE
  241. .PP
  242. detached HEAD
  243. .RS 4
  244. Normally the
  245. HEAD
  246. stores the name of a
  247. branch, and commands that operate on the history HEAD represents operate on the history leading to the tip of the branch the HEAD points at\&. However, Git also allows you to
  248. check out
  249. an arbitrary
  250. commit
  251. that isn\(cqt necessarily the tip of any particular branch\&. The HEAD in such a state is called "detached"\&.
  252. .sp
  253. Note that commands that operate on the history of the current branch (e\&.g\&.
  254. \fBgit\fR
  255. \fBcommit\fR
  256. to build a new history on top of it) still work while the HEAD is detached\&. They update the HEAD to point at the tip of the updated history without affecting any branch\&. Commands that update or inquire information
  257. \fIabout\fR
  258. the current branch (e\&.g\&.
  259. \fBgit\fR
  260. \fBbranch\fR
  261. \fB\-\-set\-upstream\-to\fR
  262. that sets what remote\-tracking branch the current branch integrates with) obviously do not work, as there is no (real) current branch to ask about in this state\&.
  263. .RE
  264. .PP
  265. directory
  266. .RS 4
  267. The list you get with "ls" :\-)
  268. .RE
  269. .PP
  270. dirty
  271. .RS 4
  272. A
  273. working tree
  274. is said to be "dirty" if it contains modifications which have not been
  275. committed
  276. to the current
  277. branch\&.
  278. .RE
  279. .PP
  280. evil merge
  281. .RS 4
  282. An evil merge is a
  283. merge
  284. that introduces changes that do not appear in any
  285. parent\&.
  286. .RE
  287. .PP
  288. fast\-forward
  289. .RS 4
  290. A fast\-forward is a special type of
  291. merge
  292. where you have a
  293. revision
  294. and you are "merging" another
  295. branch\*(Aqs changes that happen to be a descendant of what you have\&. In such a case, you do not make a new
  296. merge
  297. commit
  298. but instead just update your branch to point at the same revision as the branch you are merging\&. This will happen frequently on a
  299. remote\-tracking branch
  300. of a remote
  301. repository\&.
  302. .RE
  303. .PP
  304. fetch
  305. .RS 4
  306. Fetching a
  307. branch
  308. means to get the branch\(cqs
  309. head ref
  310. from a remote
  311. repository, to find out which objects are missing from the local
  312. object database, and to get them, too\&. See also
  313. \fBgit-fetch\fR(1)\&.
  314. .RE
  315. .PP
  316. file system
  317. .RS 4
  318. Linus Torvalds originally designed Git to be a user space file system, i\&.e\&. the infrastructure to hold files and directories\&. That ensured the efficiency and speed of Git\&.
  319. .RE
  320. .PP
  321. Git archive
  322. .RS 4
  323. Synonym for
  324. repository
  325. (for arch people)\&.
  326. .RE
  327. .PP
  328. gitfile
  329. .RS 4
  330. A plain file \&.\fBgit\fR
  331. at the root of a working tree that points at the directory that is the real repository\&. For proper use see
  332. \fBgit-worktree\fR(1)
  333. or
  334. \fBgit-submodule\fR(1)\&. For syntax see
  335. \fBgitrepository-layout\fR(5)\&.
  336. .RE
  337. .PP
  338. grafts
  339. .RS 4
  340. Grafts enable two otherwise different lines of development to be joined together by recording fake ancestry information for commits\&. This way you can make Git pretend the set of
  341. parents
  342. a
  343. commit
  344. has is different from what was recorded when the commit was created\&. Configured via the \&.\fBgit/info/grafts\fR
  345. file\&.
  346. .sp
  347. Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see
  348. \fBgit-replace\fR(1)
  349. for a more flexible and robust system to do the same thing\&.
  350. .RE
  351. .PP
  352. hash
  353. .RS 4
  354. In Git\(cqs context, synonym for
  355. object name\&.
  356. .RE
  357. .PP
  358. head
  359. .RS 4
  360. A
  361. named reference
  362. to the
  363. commit
  364. at the tip of a
  365. branch\&. Heads are stored in a file in
  366. \fB$GIT_DIR/refs/heads/\fR
  367. directory, except when using packed refs\&. (See
  368. \fBgit-pack-refs\fR(1)\&.)
  369. .RE
  370. .PP
  371. HEAD
  372. .RS 4
  373. The current
  374. branch\&. In more detail: Your
  375. working tree
  376. is normally derived from the state of the tree referred to by HEAD\&. HEAD is a reference to one of the
  377. heads
  378. in your repository, except when using a
  379. detached HEAD, in which case it directly references an arbitrary commit\&.
  380. .RE
  381. .PP
  382. head ref
  383. .RS 4
  384. A synonym for
  385. head\&.
  386. .RE
  387. .PP
  388. hook
  389. .RS 4
  390. During the normal execution of several Git commands, call\-outs are made to optional scripts that allow a developer to add functionality or checking\&. Typically, the hooks allow for a command to be pre\-verified and potentially aborted, and allow for a post\-notification after the operation is done\&. The hook scripts are found in the
  391. \fB$GIT_DIR/hooks/\fR
  392. directory, and are enabled by simply removing the \&.\fBsample\fR
  393. suffix from the filename\&. In earlier versions of Git you had to make them executable\&.
  394. .RE
  395. .PP
  396. index
  397. .RS 4
  398. A collection of files with stat information, whose contents are stored as objects\&. The index is a stored version of your
  399. working tree\&. Truth be told, it can also contain a second, and even a third version of a working tree, which are used when
  400. merging\&.
  401. .RE
  402. .PP
  403. index entry
  404. .RS 4
  405. The information regarding a particular file, stored in the
  406. index\&. An index entry can be unmerged, if a
  407. merge
  408. was started, but not yet finished (i\&.e\&. if the index contains multiple versions of that file)\&.
  409. .RE
  410. .PP
  411. master
  412. .RS 4
  413. The default development
  414. branch\&. Whenever you create a Git
  415. repository, a branch named "master" is created, and becomes the active branch\&. In most cases, this contains the local development, though that is purely by convention and is not required\&.
  416. .RE
  417. .PP
  418. merge
  419. .RS 4
  420. As a verb: To bring the contents of another
  421. branch
  422. (possibly from an external
  423. repository) into the current branch\&. In the case where the merged\-in branch is from a different repository, this is done by first
  424. fetching
  425. the remote branch and then merging the result into the current branch\&. This combination of fetch and merge operations is called a
  426. pull\&. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together\&. In cases where changes conflict, manual intervention may be required to complete the merge\&.
  427. .sp
  428. As a noun: unless it is a
  429. fast\-forward, a successful merge results in the creation of a new
  430. commit
  431. representing the result of the merge, and having as
  432. parents
  433. the tips of the merged
  434. branches\&. This commit is referred to as a "merge commit", or sometimes just a "merge"\&.
  435. .RE
  436. .PP
  437. object
  438. .RS 4
  439. The unit of storage in Git\&. It is uniquely identified by the
  440. SHA\-1
  441. of its contents\&. Consequently, an object cannot be changed\&.
  442. .RE
  443. .PP
  444. object database
  445. .RS 4
  446. Stores a set of "objects", and an individual
  447. object
  448. is identified by its
  449. object name\&. The objects usually live in
  450. \fB$GIT_DIR/objects/\fR\&.
  451. .RE
  452. .PP
  453. object identifier (oid)
  454. .RS 4
  455. Synonym for
  456. object name\&.
  457. .RE
  458. .PP
  459. object name
  460. .RS 4
  461. The unique identifier of an
  462. object\&. The object name is usually represented by a 40 character hexadecimal string\&. Also colloquially called
  463. SHA\-1\&.
  464. .RE
  465. .PP
  466. object type
  467. .RS 4
  468. One of the identifiers "commit", "tree", "tag" or "blob" describing the type of an
  469. object\&.
  470. .RE
  471. .PP
  472. octopus
  473. .RS 4
  474. To
  475. merge
  476. more than two
  477. branches\&.
  478. .RE
  479. .PP
  480. orphan
  481. .RS 4
  482. The act of getting on a
  483. branch
  484. that does not exist yet (i\&.e\&., an
  485. unborn
  486. branch)\&. After such an operation, the commit first created becomes a commit without a parent, starting a new history\&.
  487. .RE
  488. .PP
  489. origin
  490. .RS 4
  491. The default upstream
  492. repository\&. Most projects have at least one upstream project which they track\&. By default
  493. \fIorigin\fR
  494. is used for that purpose\&. New upstream updates will be fetched into
  495. remote\-tracking branches
  496. named origin/name\-of\-upstream\-branch, which you can see using
  497. \fBgit\fR
  498. \fBbranch\fR
  499. \fB\-r\fR\&.
  500. .RE
  501. .PP
  502. overlay
  503. .RS 4
  504. Only update and add files to the working directory, but don\(cqt delete them, similar to how
  505. \fIcp \-R\fR
  506. would update the contents in the destination directory\&. This is the default mode in a
  507. checkout
  508. when checking out files from the
  509. index
  510. or a
  511. tree\-ish\&. In contrast, no\-overlay mode also deletes tracked files not present in the source, similar to
  512. \fIrsync \-\-delete\fR\&.
  513. .RE
  514. .PP
  515. pack
  516. .RS 4
  517. A set of objects which have been compressed into one file (to save space or to transmit them efficiently)\&.
  518. .RE
  519. .PP
  520. pack index
  521. .RS 4
  522. The list of identifiers, and other information, of the objects in a
  523. pack, to assist in efficiently accessing the contents of a pack\&.
  524. .RE
  525. .PP
  526. pathspec
  527. .RS 4
  528. Pattern used to limit paths in Git commands\&.
  529. .sp
  530. Pathspecs are used on the command line of "git ls\-files", "git ls\-tree", "git add", "git grep", "git diff", "git checkout", and many other commands to limit the scope of operations to some subset of the tree or working tree\&. See the documentation of each command for whether paths are relative to the current directory or toplevel\&. The pathspec syntax is as follows:
  531. .sp
  532. .RS 4
  533. .ie n \{\
  534. \h'-04'\(bu\h'+03'\c
  535. .\}
  536. .el \{\
  537. .sp -1
  538. .IP \(bu 2.3
  539. .\}
  540. any path matches itself
  541. .RE
  542. .sp
  543. .RS 4
  544. .ie n \{\
  545. \h'-04'\(bu\h'+03'\c
  546. .\}
  547. .el \{\
  548. .sp -1
  549. .IP \(bu 2.3
  550. .\}
  551. the pathspec up to the last slash represents a directory prefix\&. The scope of that pathspec is limited to that subtree\&.
  552. .RE
  553. .sp
  554. .RS 4
  555. .ie n \{\
  556. \h'-04'\(bu\h'+03'\c
  557. .\}
  558. .el \{\
  559. .sp -1
  560. .IP \(bu 2.3
  561. .\}
  562. the rest of the pathspec is a pattern for the remainder of the pathname\&. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular,
  563. \fI*\fR
  564. and
  565. \fI?\fR
  566. \fIcan\fR
  567. match directory separators\&.
  568. .RE
  569. .sp
  570. For example, Documentation/*\&.jpg will match all \&.jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1\&.jpg\&.
  571. .sp
  572. A pathspec that begins with a colon
  573. \fB:\fR
  574. has special meaning\&. In the short form, the leading colon
  575. \fB:\fR
  576. is followed by zero or more "magic signature" letters (which optionally is terminated by another colon
  577. \fB:\fR), 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 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\&.
  578. .sp
  579. In the long form, the leading colon
  580. \fB:\fR
  581. is followed by an open parenthesis (, a comma\-separated list of zero or more "magic words", and a close parentheses ), and the remainder is the pattern to match against the path\&.
  582. .sp
  583. A pathspec with only a colon means "there is no pathspec"\&. This form should not be combined with other pathspec\&.
  584. .PP
  585. top
  586. .RS 4
  587. The magic word
  588. \fBtop\fR
  589. (magic signature:
  590. \fB/\fR) makes the pattern match from the root of the working tree, even when you are running the command from inside a subdirectory\&.
  591. .RE
  592. .PP
  593. literal
  594. .RS 4
  595. Wildcards in the pattern such as * or ? are treated as literal characters\&.
  596. .RE
  597. .PP
  598. icase
  599. .RS 4
  600. Case insensitive match\&.
  601. .RE
  602. .PP
  603. glob
  604. .RS 4
  605. Git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname\&. For example, "Documentation/*\&.html" matches "Documentation/git\&.html" but not "Documentation/ppc/ppc\&.html" or "tools/perf/Documentation/perf\&.html"\&.
  606. .sp
  607. Two consecutive asterisks ("**") in patterns matched against full pathname may have special meaning:
  608. .sp
  609. .RS 4
  610. .ie n \{\
  611. \h'-04'\(bu\h'+03'\c
  612. .\}
  613. .el \{\
  614. .sp -1
  615. .IP \(bu 2.3
  616. .\}
  617. A leading "**" followed by a slash means match in all directories\&. For example, "**/foo" matches file or directory "\fBfoo\fR" anywhere, the same as pattern "\fBfoo\fR"\&. "**/foo/bar" matches file or directory "\fBbar\fR" anywhere that is directly under directory "\fBfoo\fR"\&.
  618. .RE
  619. .sp
  620. .RS 4
  621. .ie n \{\
  622. \h'-04'\(bu\h'+03'\c
  623. .\}
  624. .el \{\
  625. .sp -1
  626. .IP \(bu 2.3
  627. .\}
  628. A trailing "\fB/\fR**" matches everything inside\&. For example, "\fBabc/\fR**" matches all files inside directory "abc", relative to the location of the \&.\fBgitignore\fR
  629. file, with infinite depth\&.
  630. .RE
  631. .sp
  632. .RS 4
  633. .ie n \{\
  634. \h'-04'\(bu\h'+03'\c
  635. .\}
  636. .el \{\
  637. .sp -1
  638. .IP \(bu 2.3
  639. .\}
  640. A slash followed by two consecutive asterisks then a slash matches zero or more directories\&. For example, "\fBa/\fR**/b" matches "\fBa/b\fR", "\fBa/x/b\fR", "\fBa/x/y/b\fR" and so on\&.
  641. .RE
  642. .sp
  643. .RS 4
  644. .ie n \{\
  645. \h'-04'\(bu\h'+03'\c
  646. .\}
  647. .el \{\
  648. .sp -1
  649. .IP \(bu 2.3
  650. .\}
  651. Other consecutive asterisks are considered invalid\&.
  652. .sp
  653. Glob magic is incompatible with literal magic\&.
  654. .RE
  655. .RE
  656. .PP
  657. attr
  658. .RS 4
  659. After
  660. \fBattr:\fR
  661. comes a space separated list of "attribute requirements", all of which must be met in order for the path to be considered a match; this is in addition to the usual non\-magic pathspec pattern matching\&. See
  662. \fBgitattributes\fR(5)\&.
  663. .sp
  664. Each of the attribute requirements for the path takes one of these forms:
  665. .sp
  666. .RS 4
  667. .ie n \{\
  668. \h'-04'\(bu\h'+03'\c
  669. .\}
  670. .el \{\
  671. .sp -1
  672. .IP \(bu 2.3
  673. .\}
  674. "\fBATTR\fR" requires that the attribute
  675. \fBATTR\fR
  676. be set\&.
  677. .RE
  678. .sp
  679. .RS 4
  680. .ie n \{\
  681. \h'-04'\(bu\h'+03'\c
  682. .\}
  683. .el \{\
  684. .sp -1
  685. .IP \(bu 2.3
  686. .\}
  687. "\fB\-ATTR\fR" requires that the attribute
  688. \fBATTR\fR
  689. be unset\&.
  690. .RE
  691. .sp
  692. .RS 4
  693. .ie n \{\
  694. \h'-04'\(bu\h'+03'\c
  695. .\}
  696. .el \{\
  697. .sp -1
  698. .IP \(bu 2.3
  699. .\}
  700. "\fBATTR=VALUE\fR" requires that the attribute
  701. \fBATTR\fR
  702. be set to the string
  703. \fBVALUE\fR\&.
  704. .RE
  705. .sp
  706. .RS 4
  707. .ie n \{\
  708. \h'-04'\(bu\h'+03'\c
  709. .\}
  710. .el \{\
  711. .sp -1
  712. .IP \(bu 2.3
  713. .\}
  714. "!ATTR" requires that the attribute
  715. \fBATTR\fR
  716. be unspecified\&.
  717. .sp
  718. Note that when matching against a tree object, attributes are still obtained from working tree, not from the given tree object\&.
  719. .RE
  720. .RE
  721. .PP
  722. exclude
  723. .RS 4
  724. After a path matches any non\-exclude pathspec, it will be run through all exclude pathspecs (magic signature: ! or its synonym
  725. \fB^\fR)\&. If it matches, the path is ignored\&. When there is no non\-exclude pathspec, the exclusion is applied to the result set as if invoked without any pathspec\&.
  726. .RE
  727. .RE
  728. .PP
  729. parent
  730. .RS 4
  731. A
  732. commit object
  733. contains a (possibly empty) list of the logical predecessor(s) in the line of development, i\&.e\&. its parents\&.
  734. .RE
  735. .PP
  736. peel
  737. .RS 4
  738. The action of recursively
  739. dereferencing
  740. a
  741. tag object\&.
  742. .RE
  743. .PP
  744. pickaxe
  745. .RS 4
  746. The term
  747. pickaxe
  748. refers to an option to the diffcore routines that help select changes that add or delete a given text string\&. With the
  749. \fB\-\-pickaxe\-all\fR
  750. option, it can be used to view the full
  751. changeset
  752. that introduced or removed, say, a particular line of text\&. See
  753. \fBgit-diff\fR(1)\&.
  754. .RE
  755. .PP
  756. plumbing
  757. .RS 4
  758. Cute name for
  759. core Git\&.
  760. .RE
  761. .PP
  762. porcelain
  763. .RS 4
  764. Cute name for programs and program suites depending on
  765. core Git, presenting a high level access to core Git\&. Porcelains expose more of a
  766. SCM
  767. interface than the
  768. plumbing\&.
  769. .RE
  770. .PP
  771. per\-worktree ref
  772. .RS 4
  773. Refs that are per\-worktree, rather than global\&. This is presently only
  774. HEAD
  775. and any refs that start with
  776. \fBrefs/bisect/\fR, but might later include other unusual refs\&.
  777. .RE
  778. .PP
  779. pseudoref
  780. .RS 4
  781. A ref that has different semantics than normal refs\&. These refs can be read via normal Git commands, but cannot be written to by commands like
  782. \fBgit-update-ref\fR(1)\&.
  783. .sp
  784. The following pseudorefs are known to Git:
  785. .sp
  786. .RS 4
  787. .ie n \{\
  788. \h'-04'\(bu\h'+03'\c
  789. .\}
  790. .el \{\
  791. .sp -1
  792. .IP \(bu 2.3
  793. .\}
  794. \fBFETCH_HEAD\fR
  795. is written by
  796. \fBgit-fetch\fR(1)
  797. or
  798. \fBgit-pull\fR(1)\&. It may refer to multiple object IDs\&. Each object ID is annotated with metadata indicating where it was fetched from and its fetch status\&.
  799. .RE
  800. .sp
  801. .RS 4
  802. .ie n \{\
  803. \h'-04'\(bu\h'+03'\c
  804. .\}
  805. .el \{\
  806. .sp -1
  807. .IP \(bu 2.3
  808. .\}
  809. \fBMERGE_HEAD\fR
  810. is written by
  811. \fBgit-merge\fR(1)
  812. when resolving merge conflicts\&. It contains all commit IDs which are being merged\&.
  813. .RE
  814. .RE
  815. .PP
  816. pull
  817. .RS 4
  818. Pulling a
  819. branch
  820. means to
  821. fetch
  822. it and
  823. merge
  824. it\&. See also
  825. \fBgit-pull\fR(1)\&.
  826. .RE
  827. .PP
  828. push
  829. .RS 4
  830. Pushing a
  831. branch
  832. means to get the branch\(cqs
  833. head ref
  834. from a remote
  835. repository, find out if it is an ancestor to the branch\(cqs local head ref, and in that case, putting all objects, which are
  836. reachable
  837. from the local head ref, and which are missing from the remote repository, into the remote
  838. object database, and updating the remote head ref\&. If the remote
  839. head
  840. is not an ancestor to the local head, the push fails\&.
  841. .RE
  842. .PP
  843. reachable
  844. .RS 4
  845. All of the ancestors of a given
  846. commit
  847. are said to be "reachable" from that commit\&. More generally, one
  848. object
  849. is reachable from another if we can reach the one from the other by a
  850. chain
  851. that follows
  852. tags
  853. to whatever they tag,
  854. commits
  855. to their parents or trees, and
  856. trees
  857. to the trees or
  858. blobs
  859. that they contain\&.
  860. .RE
  861. .PP
  862. reachability bitmaps
  863. .RS 4
  864. Reachability bitmaps store information about the
  865. reachability
  866. of a selected set of commits in a packfile, or a multi\-pack index (MIDX), to speed up object search\&. The bitmaps are stored in a "\&.bitmap" file\&. A repository may have at most one bitmap file in use\&. The bitmap file may belong to either one pack, or the repository\(cqs multi\-pack index (if it exists)\&.
  867. .RE
  868. .PP
  869. rebase
  870. .RS 4
  871. To reapply a series of changes from a
  872. branch
  873. to a different base, and reset the
  874. head
  875. of that branch to the result\&.
  876. .RE
  877. .PP
  878. ref
  879. .RS 4
  880. A name that points to an
  881. object name
  882. or another ref (the latter is called a
  883. symbolic ref)\&. For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see
  884. \fBgitrevisions\fR(7)
  885. for details\&. Refs are stored in the
  886. repository\&.
  887. .sp
  888. The ref namespace is hierarchical\&. Ref names must either start with
  889. \fBrefs/\fR
  890. or be located in the root of the hierarchy\&. For the latter, their name must follow these rules:
  891. .sp
  892. .RS 4
  893. .ie n \{\
  894. \h'-04'\(bu\h'+03'\c
  895. .\}
  896. .el \{\
  897. .sp -1
  898. .IP \(bu 2.3
  899. .\}
  900. The name consists of only upper\-case characters or underscores\&.
  901. .RE
  902. .sp
  903. .RS 4
  904. .ie n \{\
  905. \h'-04'\(bu\h'+03'\c
  906. .\}
  907. .el \{\
  908. .sp -1
  909. .IP \(bu 2.3
  910. .\}
  911. The name ends with "\fB_HEAD\fR" or is equal to "\fBHEAD\fR"\&.
  912. .sp
  913. There are some irregular refs in the root of the hierarchy that do not match these rules\&. The following list is exhaustive and shall not be extended in the future:
  914. .RE
  915. .sp
  916. .RS 4
  917. .ie n \{\
  918. \h'-04'\(bu\h'+03'\c
  919. .\}
  920. .el \{\
  921. .sp -1
  922. .IP \(bu 2.3
  923. .\}
  924. \fBAUTO_MERGE\fR
  925. .RE
  926. .sp
  927. .RS 4
  928. .ie n \{\
  929. \h'-04'\(bu\h'+03'\c
  930. .\}
  931. .el \{\
  932. .sp -1
  933. .IP \(bu 2.3
  934. .\}
  935. \fBBISECT_EXPECTED_REV\fR
  936. .RE
  937. .sp
  938. .RS 4
  939. .ie n \{\
  940. \h'-04'\(bu\h'+03'\c
  941. .\}
  942. .el \{\
  943. .sp -1
  944. .IP \(bu 2.3
  945. .\}
  946. \fBNOTES_MERGE_PARTIAL\fR
  947. .RE
  948. .sp
  949. .RS 4
  950. .ie n \{\
  951. \h'-04'\(bu\h'+03'\c
  952. .\}
  953. .el \{\
  954. .sp -1
  955. .IP \(bu 2.3
  956. .\}
  957. \fBNOTES_MERGE_REF\fR
  958. .RE
  959. .sp
  960. .RS 4
  961. .ie n \{\
  962. \h'-04'\(bu\h'+03'\c
  963. .\}
  964. .el \{\
  965. .sp -1
  966. .IP \(bu 2.3
  967. .\}
  968. \fBMERGE_AUTOSTASH\fR
  969. .sp
  970. Different subhierarchies are used for different purposes\&. For example, the
  971. \fBrefs/heads/\fR
  972. hierarchy is used to represent local branches whereas the
  973. \fBrefs/tags/\fR
  974. hierarchy is used to represent local tags\&.\&.
  975. .RE
  976. .RE
  977. .PP
  978. reflog
  979. .RS 4
  980. A reflog shows the local "history" of a ref\&. In other words, it can tell you what the 3rd last revision in
  981. \fIthis\fR
  982. repository was, and what was the current state in
  983. \fIthis\fR
  984. repository, yesterday 9:14pm\&. See
  985. \fBgit-reflog\fR(1)
  986. for details\&.
  987. .RE
  988. .PP
  989. refspec
  990. .RS 4
  991. A "refspec" is used by
  992. fetch
  993. and
  994. push
  995. to describe the mapping between remote
  996. ref
  997. and local ref\&. See
  998. \fBgit-fetch\fR(1)
  999. or
  1000. \fBgit-push\fR(1)
  1001. for details\&.
  1002. .RE
  1003. .PP
  1004. remote repository
  1005. .RS 4
  1006. A
  1007. repository
  1008. which is used to track the same project but resides somewhere else\&. To communicate with remotes, see
  1009. fetch
  1010. or
  1011. push\&.
  1012. .RE
  1013. .PP
  1014. remote\-tracking branch
  1015. .RS 4
  1016. A
  1017. ref
  1018. that is used to follow changes from another
  1019. repository\&. It typically looks like
  1020. \fIrefs/remotes/foo/bar\fR
  1021. (indicating that it tracks a branch named
  1022. \fIbar\fR
  1023. in a remote named
  1024. \fIfoo\fR), and matches the right\-hand\-side of a configured fetch
  1025. refspec\&. A remote\-tracking branch should not contain direct modifications or have local commits made to it\&.
  1026. .RE
  1027. .PP
  1028. repository
  1029. .RS 4
  1030. A collection of
  1031. refs
  1032. together with an
  1033. object database
  1034. containing all objects which are
  1035. reachable
  1036. from the refs, possibly accompanied by meta data from one or more
  1037. porcelains\&. A repository can share an object database with other repositories via
  1038. alternates mechanism\&.
  1039. .RE
  1040. .PP
  1041. resolve
  1042. .RS 4
  1043. The action of fixing up manually what a failed automatic
  1044. merge
  1045. left behind\&.
  1046. .RE
  1047. .PP
  1048. revision
  1049. .RS 4
  1050. Synonym for
  1051. commit
  1052. (the noun)\&.
  1053. .RE
  1054. .PP
  1055. rewind
  1056. .RS 4
  1057. To throw away part of the development, i\&.e\&. to assign the
  1058. head
  1059. to an earlier
  1060. revision\&.
  1061. .RE
  1062. .PP
  1063. SCM
  1064. .RS 4
  1065. Source code management (tool)\&.
  1066. .RE
  1067. .PP
  1068. SHA\-1
  1069. .RS 4
  1070. "Secure Hash Algorithm 1"; a cryptographic hash function\&. In the context of Git used as a synonym for
  1071. object name\&.
  1072. .RE
  1073. .PP
  1074. shallow clone
  1075. .RS 4
  1076. Mostly a synonym to
  1077. shallow repository
  1078. but the phrase makes it more explicit that it was created by running
  1079. \fBgit\fR
  1080. \fBclone\fR
  1081. \fB\-\-depth=\&.\&.\fR\&. command\&.
  1082. .RE
  1083. .PP
  1084. shallow repository
  1085. .RS 4
  1086. A shallow
  1087. repository
  1088. has an incomplete history some of whose
  1089. commits
  1090. have
  1091. parents
  1092. cauterized away (in other words, Git is told to pretend that these commits do not have the parents, even though they are recorded in the
  1093. commit object)\&. This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger\&. A shallow repository is created by giving the
  1094. \fB\-\-depth\fR
  1095. option to
  1096. \fBgit-clone\fR(1), and its history can be later deepened with
  1097. \fBgit-fetch\fR(1)\&.
  1098. .RE
  1099. .PP
  1100. stash entry
  1101. .RS 4
  1102. An
  1103. object
  1104. used to temporarily store the contents of a
  1105. dirty
  1106. working directory and the index for future reuse\&.
  1107. .RE
  1108. .PP
  1109. submodule
  1110. .RS 4
  1111. A
  1112. repository
  1113. that holds the history of a separate project inside another repository (the latter of which is called
  1114. superproject)\&.
  1115. .RE
  1116. .PP
  1117. superproject
  1118. .RS 4
  1119. A
  1120. repository
  1121. that references repositories of other projects in its working tree as
  1122. submodules\&. The superproject knows about the names of (but does not hold copies of) commit objects of the contained submodules\&.
  1123. .RE
  1124. .PP
  1125. symref
  1126. .RS 4
  1127. Symbolic reference: instead of containing the
  1128. SHA\-1
  1129. id itself, it is of the format
  1130. \fIref: refs/some/thing\fR
  1131. and when referenced, it recursively
  1132. dereferences
  1133. to this reference\&.
  1134. \fIHEAD\fR
  1135. is a prime example of a symref\&. Symbolic references are manipulated with the
  1136. \fBgit-symbolic-ref\fR(1)
  1137. command\&.
  1138. .RE
  1139. .PP
  1140. tag
  1141. .RS 4
  1142. A
  1143. ref
  1144. under
  1145. \fBrefs/tags/\fR
  1146. namespace that points to an object of an arbitrary type (typically a tag points to either a
  1147. tag
  1148. or a
  1149. commit object)\&. In contrast to a
  1150. head, a tag is not updated by the
  1151. \fBcommit\fR
  1152. command\&. A Git tag has nothing to do with a Lisp tag (which would be called an
  1153. object type
  1154. in Git\(cqs context)\&. A tag is most typically used to mark a particular point in the commit ancestry
  1155. chain\&.
  1156. .RE
  1157. .PP
  1158. tag object
  1159. .RS 4
  1160. An
  1161. object
  1162. containing a
  1163. ref
  1164. pointing to another object, which can contain a message just like a
  1165. commit object\&. It can also contain a (PGP) signature, in which case it is called a "signed tag object"\&.
  1166. .RE
  1167. .PP
  1168. topic branch
  1169. .RS 4
  1170. A regular Git
  1171. branch
  1172. that is used by a developer to identify a conceptual line of development\&. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet related changes\&.
  1173. .RE
  1174. .PP
  1175. trailer
  1176. .RS 4
  1177. Key\-value metadata\&. Trailers are optionally found at the end of a commit message\&. Might be called "footers" or "tags" in other communities\&. See
  1178. \fBgit-interpret-trailers\fR(1)\&.
  1179. .RE
  1180. .PP
  1181. tree
  1182. .RS 4
  1183. Either a
  1184. working tree, or a
  1185. tree object
  1186. together with the dependent
  1187. blob
  1188. and tree objects (i\&.e\&. a stored representation of a working tree)\&.
  1189. .RE
  1190. .PP
  1191. tree object
  1192. .RS 4
  1193. An
  1194. object
  1195. containing a list of file names and modes along with refs to the associated blob and/or tree objects\&. A
  1196. tree
  1197. is equivalent to a
  1198. directory\&.
  1199. .RE
  1200. .PP
  1201. tree\-ish (also treeish)
  1202. .RS 4
  1203. A
  1204. tree object
  1205. or an
  1206. object
  1207. that can be recursively
  1208. dereferenced
  1209. to a tree object\&. Dereferencing a
  1210. commit object
  1211. yields the tree object corresponding to the
  1212. revision\*(Aqs top
  1213. directory\&. The following are all tree\-ishes: a
  1214. commit\-ish, a tree object, a
  1215. tag object
  1216. that points to a tree object, a tag object that points to a tag object that points to a tree object, etc\&.
  1217. .RE
  1218. .PP
  1219. unborn
  1220. .RS 4
  1221. The
  1222. HEAD
  1223. can point at a
  1224. branch
  1225. that does not yet exist and that does not have any commit on it yet, and such a branch is called an unborn branch\&. The most typical way users encounter an unborn branch is by creating a repository anew without cloning from elsewhere\&. The HEAD would point at the
  1226. \fImain\fR
  1227. (or
  1228. \fImaster\fR, depending on your configuration) branch that is yet to be born\&. Also some operations can get you on an unborn branch with their
  1229. orphan
  1230. option\&.
  1231. .RE
  1232. .PP
  1233. unmerged index
  1234. .RS 4
  1235. An
  1236. index
  1237. which contains unmerged
  1238. index entries\&.
  1239. .RE
  1240. .PP
  1241. unreachable object
  1242. .RS 4
  1243. An
  1244. object
  1245. which is not
  1246. reachable
  1247. from a
  1248. branch,
  1249. tag, or any other reference\&.
  1250. .RE
  1251. .PP
  1252. upstream branch
  1253. .RS 4
  1254. The default
  1255. branch
  1256. that is merged into the branch in question (or the branch in question is rebased onto)\&. It is configured via branch\&.<name>\&.remote and branch\&.<name>\&.merge\&. If the upstream branch of
  1257. \fIA\fR
  1258. is
  1259. \fIorigin/B\fR
  1260. sometimes we say "\fIA\fR
  1261. is tracking
  1262. \fIorigin/B\fR"\&.
  1263. .RE
  1264. .PP
  1265. working tree
  1266. .RS 4
  1267. The tree of actual checked out files\&. The working tree normally contains the contents of the
  1268. HEAD
  1269. commit\(cqs tree, plus any local changes that you have made but not yet committed\&.
  1270. .RE
  1271. .PP
  1272. worktree
  1273. .RS 4
  1274. A repository can have zero (i\&.e\&. bare repository) or one or more worktrees attached to it\&. One "worktree" consists of a "working tree" and repository metadata, most of which are shared among other worktrees of a single repository, and some of which are maintained separately per worktree (e\&.g\&. the index, HEAD and pseudorefs like MERGE_HEAD, per\-worktree refs and per\-worktree configuration file)\&.
  1275. .RE
  1276. .SH "SEE ALSO"
  1277. .sp
  1278. \fBgittutorial\fR(7), \fBgittutorial-2\fR(7), \fBgitcvs-migration\fR(7), \fBgiteveryday\fR(7), \m[blue]\fBThe Git User\(cqs Manual\fR\m[]\&\s-2\u[1]\d\s+2
  1279. .SH "GIT"
  1280. .sp
  1281. Part of the \fBgit\fR(1) suite
  1282. .SH "NOTES"
  1283. .IP " 1." 4
  1284. The Git User\(cqs Manual
  1285. .RS 4
  1286. \%git-htmldocs/user-manual.html
  1287. .RE