Added option to export the marks table when fast-import terminates.
[git] / Documentation / glossary.txt
1 alternate object database::
2         Via the alternates mechanism, a repository can inherit part of its
3         object database from another object database, which is called
4         "alternate".
5
6 bare repository::
7         A bare repository is normally an appropriately named
8         directory with a `.git` suffix that does not have a
9         locally checked-out copy of any of the files under revision
10         control.  That is, all of the `git` administrative and
11         control files that would normally be present in the
12         hidden `.git` sub-directory are directly present in
13         the `repository.git` directory instead, and no other files
14         are present and checked out.  Usually publishers of public
15         repositories make bare repositories available.
16
17 blob object::
18         Untyped object, e.g. the contents of a file.
19
20 branch::
21         A non-cyclical graph of revisions, i.e. the complete history of
22         a particular revision, which is called the branch head. The
23         branch heads are stored in `$GIT_DIR/refs/heads/`.
24
25 cache::
26         Obsolete for: index.
27
28 chain::
29         A list of objects, where each object in the list contains a
30         reference to its successor (for example, the successor of a commit
31         could be one of its parents).
32
33 changeset::
34         BitKeeper/cvsps speak for "commit". Since git does not store
35         changes, but states, it really does not make sense to use
36         the term "changesets" with git.
37
38 checkout::
39         The action of updating the working tree to a revision which was
40         stored in the object database.
41
42 cherry-picking::
43         In SCM jargon, "cherry pick" means to choose a subset of
44         changes out of a series of changes (typically commits)
45         and record them as a new series of changes on top of
46         different codebase.  In GIT, this is performed by
47         "git cherry-pick" command to extract the change
48         introduced by an existing commit and to record it based
49         on the tip of the current branch as a new commit.
50
51 clean::
52         A working tree is clean, if it corresponds to the revision
53         referenced by the current head.  Also see "dirty".
54
55 commit::
56         As a verb: The action of storing the current state of the index in the
57         object database. The result is a revision.
58         As a noun: Short hand for commit object.
59
60 commit object::
61         An object which contains the information about a particular
62         revision, such as parents, committer, author, date and the
63         tree object which corresponds to the top directory of the
64         stored revision.
65
66 core git::
67         Fundamental data structures and utilities of git. Exposes only
68         limited source code management tools.
69
70 DAG::
71         Directed acyclic graph. The commit objects form a directed acyclic
72         graph, because they have parents (directed), and the graph of commit
73         objects is acyclic (there is no chain which begins and ends with the
74         same object).
75
76 dircache::
77         You are *waaaaay* behind.
78
79 dirty::
80         A working tree is said to be dirty if it contains modifications
81         which have not been committed to the current branch.
82
83 directory::
84         The list you get with "ls" :-)
85
86 ent::
87         Favorite synonym to "tree-ish" by some total geeks. See
88         `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
89         explanation.  Avoid this term, not to confuse people.
90
91 fast forward::
92         A fast-forward is a special type of merge where you have
93         a revision and you are "merging" another branch's changes
94         that happen to be a descendant of what you have.
95         In such these cases, you do not make a new merge commit but
96         instead just update to his revision. This will happen
97         frequently on a tracking branch of a remote repository.
98
99 fetch::
100         Fetching a branch means to get the branch's head ref from a
101         remote repository, to find out which objects are missing from
102         the local object database, and to get them, too.
103
104 file system::
105         Linus Torvalds originally designed git to be a user space file
106         system, i.e. the infrastructure to hold files and directories.
107         That ensured the efficiency and speed of git.
108
109 git archive::
110         Synonym for repository (for arch people).
111
112 grafts::
113         Grafts enables two otherwise different lines of development to be
114         joined together by recording fake ancestry information for commits.
115         This way you can make git pretend the set of parents a commit
116         has is different from what was recorded when the commit was created.
117         Configured via the `.git/info/grafts` file.
118
119 hash::
120         In git's context, synonym to object name.
121
122 head::
123         The top of a branch. It contains a ref to the corresponding
124         commit object.
125
126 head ref::
127         A ref pointing to a head. Often, this is abbreviated to "head".
128         Head refs are stored in `$GIT_DIR/refs/heads/`.
129
130 hook::
131         During the normal execution of several git commands,
132         call-outs are made to optional scripts that allow
133         a developer to add functionality or checking.
134         Typically, the hooks allow for a command to be pre-verified
135         and potentially aborted, and allow for a post-notification
136         after the operation is done.
137         The hook scripts are found in the `$GIT_DIR/hooks/` directory,
138         and are enabled by simply making them executable.
139
140 index::
141         A collection of files with stat information, whose contents are
142         stored as objects. The index is a stored version of your working
143         tree. Truth be told, it can also contain a second, and even a third
144         version of a working tree, which are used when merging.
145
146 index entry::
147         The information regarding a particular file, stored in the index.
148         An index entry can be unmerged, if a merge was started, but not
149         yet finished (i.e. if the index contains multiple versions of
150         that file).
151
152 master::
153         The default development branch. Whenever you create a git
154         repository, a branch named "master" is created, and becomes
155         the active branch. In most cases, this contains the local
156         development, though that is purely conventional and not required.
157
158 merge::
159         To merge branches means to try to accumulate the changes since a
160         common ancestor and apply them to the first branch. An automatic
161         merge uses heuristics to accomplish that. Evidently, an automatic
162         merge can fail.
163
164 object::
165         The unit of storage in git. It is uniquely identified by
166         the SHA1 of its contents. Consequently, an object can not
167         be changed.
168
169 object database::
170         Stores a set of "objects", and an individual object is identified
171         by its object name. The objects usually live in `$GIT_DIR/objects/`.
172
173 object identifier::
174         Synonym for object name.
175
176 object name::
177         The unique identifier of an object. The hash of the object's contents
178         using the Secure Hash Algorithm 1 and usually represented by the 40
179         character hexadecimal encoding of the hash of the object (possibly
180         followed by a white space).
181
182 object type:
183         One of the identifiers "commit","tree","tag" and "blob" describing
184         the type of an object.
185
186 octopus::
187         To merge more than two branches. Also denotes an intelligent
188         predator.
189
190 origin::
191         The default upstream tracking branch. Most projects have at
192         least one upstream project which they track. By default
193         'origin' is used for that purpose.  New upstream updates
194         will be fetched into this branch; you should never commit
195         to it yourself.
196
197 pack::
198         A set of objects which have been compressed into one file (to save
199         space or to transmit them efficiently).
200
201 pack index::
202         The list of identifiers, and other information, of the objects in a
203         pack, to assist in efficiently accessing the contents of a pack.
204
205 parent::
206         A commit object contains a (possibly empty) list of the logical
207         predecessor(s) in the line of development, i.e. its parents.
208
209 pickaxe::
210         The term pickaxe refers to an option to the diffcore routines
211         that help select changes that add or delete a given text string.
212         With the --pickaxe-all option, it can be used to view the
213         full changeset that introduced or removed, say, a particular
214         line of text.  See gitlink:git-diff[1].
215
216 plumbing::
217         Cute name for core git.
218
219 porcelain::
220         Cute name for programs and program suites depending on core git,
221         presenting a high level access to core git. Porcelains expose
222         more of a SCM interface than the plumbing.
223
224 pull::
225         Pulling a branch means to fetch it and merge it.
226
227 push::
228         Pushing a branch means to get the branch's head ref from a remote
229         repository, find out if it is an ancestor to the branch's local
230         head ref is a direct, and in that case, putting all objects, which
231         are reachable from the local head ref, and which are missing from
232         the remote repository, into the remote object database, and updating
233         the remote head ref. If the remote head is not an ancestor to the
234         local head, the push fails.
235
236 reachable::
237         An object is reachable from a ref/commit/tree/tag, if there is a
238         chain leading from the latter to the former.
239
240 rebase::
241         To clean a branch by starting from the head of the main line of
242         development ("master"), and reapply the (possibly cherry-picked)
243         changes from that branch.
244
245 ref::
246         A 40-byte hex representation of a SHA1 or a name that denotes
247         a particular object. These may be stored in `$GIT_DIR/refs/`.
248
249 refspec::
250         A refspec is used by fetch and push to describe the mapping
251         between remote ref and local ref.  They are combined with
252         a colon in the format <src>:<dst>, preceded by an optional
253         plus sign, +.  For example:
254         `git fetch $URL refs/heads/master:refs/heads/origin`
255         means "grab the master branch head from the $URL and store
256         it as my origin branch head".
257         And `git push $URL refs/heads/master:refs/heads/to-upstream`
258         means "publish my master branch head as to-upstream master head
259         at $URL".   See also gitlink:git-push[1]
260
261 repository::
262         A collection of refs together with an object database containing
263         all objects, which are reachable from the refs, possibly accompanied
264         by meta data from one or more porcelains. A repository can
265         share an object database with other repositories.
266
267 resolve::
268         The action of fixing up manually what a failed automatic merge
269         left behind.
270
271 revision::
272         A particular state of files and directories which was stored in
273         the object database. It is referenced by a commit object.
274
275 rewind::
276         To throw away part of the development, i.e. to assign the head to
277         an earlier revision.
278
279 SCM::
280         Source code management (tool).
281
282 SHA1::
283         Synonym for object name.
284
285 topic branch::
286         A regular git branch that is used by a developer to
287         identify a conceptual line of development.  Since branches
288         are very easy and inexpensive, it is often desirable to
289         have several small branches that each contain very well
290         defined concepts or small incremental yet related changes.
291
292 tracking branch::
293         A regular git branch that is used to follow changes from
294         another repository.  A tracking branch should not contain
295         direct modifications or have local commits made to it.
296         A tracking branch can usually be identified as the
297         right-hand-side ref in a Pull: refspec.
298
299 tree object::
300         An object containing a list of file names and modes along with refs
301         to the associated blob and/or tree objects. A tree is equivalent
302         to a directory.
303
304 tree::
305         Either a working tree, or a tree object together with the
306         dependent blob and tree objects (i.e. a stored representation
307         of a working tree).
308
309 tree-ish::
310         A ref pointing to either a commit object, a tree object, or a
311         tag object pointing to a tag or commit or tree object.
312
313 tag object::
314         An object containing a ref pointing to another object, which can
315         contain a message just like a commit object. It can also
316         contain a (PGP) signature, in which case it is called a "signed
317         tag object".
318
319 tag::
320         A ref pointing to a tag or commit object. In contrast to a head,
321         a tag is not changed by a commit. Tags (not tag objects) are
322         stored in `$GIT_DIR/refs/tags/`. A git tag has nothing to do with
323         a Lisp tag (which is called object type in git's context).
324         A tag is most typically used to mark a particular point in the
325         commit ancestry chain.
326
327 unmerged index:
328         An index which contains unmerged index entries.
329
330 working tree::
331         The set of files and directories currently being worked on,
332         i.e. you can work in your working tree without using git at all.
333