Google Git
Sign in
chromium / external / gitster / git-htmldocs / 79770b6ed3e6b40355c01e4d1c00c0da5c827086 / . / glossary.html
blob: d77cbe1c945ef4c8c334184f8a5b3ed49a6bb210 [file] [log] [blame]
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]1<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
2 "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
3<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
4<head>
5<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]6<meta name="generator" content="AsciiDoc 7.0.2" />
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]7<style type="text/css">
8/* Debug borders */
9p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
10/*
11 border: 1px solid red;
12*/
13}
14
15body {
16 margin: 1em 5% 1em 5%;
17}
18
19a { color: blue; }
20a:visited { color: fuchsia; }
21
22em {
23 font-style: italic;
24}
25
26strong {
27 font-weight: bold;
28}
29
30tt {
31 color: navy;
32}
33
34h1, h2, h3, h4, h5, h6 {
35 color: #527bbd;
36 font-family: sans-serif;
37 margin-top: 1.2em;
38 margin-bottom: 0.5em;
39 line-height: 1.3;
40}
41
42h1 {
43 border-bottom: 2px solid silver;
44}
45h2 {
46 border-bottom: 2px solid silver;
47 padding-top: 0.5em;
48}
49
50div.sectionbody {
51 font-family: serif;
52 margin-left: 0;
53}
54
55hr {
56 border: 1px solid silver;
57}
58
59p {
60 margin-top: 0.5em;
61 margin-bottom: 0.5em;
62}
63
64pre {
65 padding: 0;
66 margin: 0;
67}
68
69span#author {
70 color: #527bbd;
71 font-family: sans-serif;
72 font-weight: bold;
73 font-size: 1.2em;
74}
75span#email {
76}
77span#revision {
78 font-family: sans-serif;
79}
80
81div#footer {
82 font-family: sans-serif;
83 font-size: small;
84 border-top: 2px solid silver;
85 padding-top: 0.5em;
86 margin-top: 4.0em;
87}
88div#footer-text {
89 float: left;
90 padding-bottom: 0.5em;
91}
92div#footer-badges {
93 float: right;
94 padding-bottom: 0.5em;
95}
96
97div#preamble,
98div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
99div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
100div.admonitionblock {
101 margin-right: 10%;
102 margin-top: 1.5em;
103 margin-bottom: 1.5em;
104}
105div.admonitionblock {
106 margin-top: 2.5em;
107 margin-bottom: 2.5em;
108}
109
110div.content { /* Block element content. */
111 padding: 0;
112}
113
114/* Block element titles. */
115div.title, caption.title {
116 font-family: sans-serif;
117 font-weight: bold;
118 text-align: left;
119 margin-top: 1.0em;
120 margin-bottom: 0.5em;
121}
122div.title + * {
123 margin-top: 0;
124}
125
126td div.title:first-child {
127 margin-top: 0.0em;
128}
129div.content div.title:first-child {
130 margin-top: 0.0em;
131}
132div.content + div.title {
133 margin-top: 0.0em;
134}
135
136div.sidebarblock > div.content {
137 background: #ffffee;
138 border: 1px solid silver;
139 padding: 0.5em;
140}
141
142div.listingblock > div.content {
143 border: 1px solid silver;
144 background: #f4f4f4;
145 padding: 0.5em;
146}
147
148div.quoteblock > div.content {
149 padding-left: 2.0em;
150}
151div.quoteblock .attribution {
152 text-align: right;
153}
154
155div.admonitionblock .icon {
156 vertical-align: top;
157 font-size: 1.1em;
158 font-weight: bold;
159 text-decoration: underline;
160 color: #527bbd;
161 padding-right: 0.5em;
162}
163div.admonitionblock td.content {
164 padding-left: 0.5em;
165 border-left: 2px solid silver;
166}
167
168div.exampleblock > div.content {
169 border-left: 2px solid silver;
170 padding: 0.5em;
171}
172
173div.verseblock div.content {
174 white-space: pre;
175}
176
177div.imageblock div.content { padding-left: 0; }
178div.imageblock img { border: 1px solid silver; }
179span.image img { border-style: none; }
180
181dl {
182 margin-top: 0.8em;
183 margin-bottom: 0.8em;
184}
185dt {
186 margin-top: 0.5em;
187 margin-bottom: 0;
188 font-style: italic;
189}
190dd > *:first-child {
191 margin-top: 0;
192}
193
194ul, ol {
195 list-style-position: outside;
196}
197ol.olist2 {
198 list-style-type: lower-alpha;
199}
200
201div.tableblock > table {
202 border-color: #527bbd;
203 border-width: 3px;
204}
205thead {
206 font-family: sans-serif;
207 font-weight: bold;
208}
209tfoot {
210 font-weight: bold;
211}
212
213div.hlist {
214 margin-top: 0.8em;
215 margin-bottom: 0.8em;
216}
217td.hlist1 {
218 vertical-align: top;
219 font-style: italic;
220 padding-right: 0.8em;
221}
222td.hlist2 {
223 vertical-align: top;
224}
225
226@media print {
227 div#footer-badges { display: none; }
228}
229/* Workarounds for IE6's broken and incomplete CSS2. */
230
231div.sidebar-content {
232 background: #ffffee;
233 border: 1px solid silver;
234 padding: 0.5em;
235}
236div.sidebar-title, div.image-title {
237 font-family: sans-serif;
238 font-weight: bold;
239 margin-top: 0.0em;
240 margin-bottom: 0.5em;
241}
242
243div.listingblock div.content {
244 border: 1px solid silver;
245 background: #f4f4f4;
246 padding: 0.5em;
247}
248
249div.quoteblock-content {
250 padding-left: 2.0em;
251}
252
253div.exampleblock-content {
254 border-left: 2px solid silver;
255 padding-left: 0.5em;
256}
257</style>
258<title>GIT Glossary</title>
259</head>
260<body>
261<div id="header">
262<h1>GIT Glossary</h1>
263</div>
264<div id="preamble">
265<div class="sectionbody">
266<p>This list is sorted alphabetically:</p>
267<dl>
268<dt>
269<a id="ref_alternate_object_database"></a>alternate object database
270</dt>
271<dd>
272<p>
273 Via the alternates mechanism, a <a href="#ref_repository">repository</a> can
274 inherit part of its <a href="#ref_object_database">object database</a> from another
275 <a href="#ref_object_database">object database</a>, which is called "alternate".
276</p>
277</dd>
278<dt>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]279<a id="ref_bare_repository"></a>bare repository
280</dt>
281<dd>
282<p>
283 A <a href="#ref_bare_repository">bare repository</a> is normally an appropriately
284 named <a href="#ref_directory">directory</a> with a <tt>.git</tt> suffix that does not
285 have a locally checked-out copy of any of the files under
286 <a href="#ref_revision">revision</a> control. That is, all of the <tt>git</tt>
287 administrative and control files that would normally be present in the
288 hidden <tt>.git</tt> sub-<a href="#ref_directory">directory</a> are directly present in
289 the <tt><a href="#ref_repository">repository</a>.git</tt> <a href="#ref_directory">directory</a>
290 instead, and no other files are present and checked out. Usually
291 publishers of public repositories make bare repositories available.
292</p>
293</dd>
294<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]295<a id="ref_blob_object"></a>blob object
296</dt>
297<dd>
298<p>
299 Untyped <a href="#ref_object">object</a>, e.g. the contents of a file.
300</p>
301</dd>
302<dt>
303<a id="ref_branch"></a>branch
304</dt>
305<dd>
306<p>
307 A non-cyclical graph of revisions, i.e. the complete history of a
308 particular <a href="#ref_revision">revision</a>, which is called the
309 <a href="#ref_branch">branch</a> <a href="#ref_head">head</a>. The <a href="#ref_branch">branch</a> heads
310 are stored in <tt>$GIT_DIR/refs/heads/</tt>.
311</p>
312</dd>
313<dt>
314<a id="ref_cache"></a>cache
315</dt>
316<dd>
317<p>
318 Obsolete for: <a href="#ref_index">index</a>.
319</p>
320</dd>
321<dt>
322<a id="ref_chain"></a>chain
323</dt>
324<dd>
325<p>
326 A list of objects, where each <a href="#ref_object">object</a> in the list contains
327 a reference to its successor (for example, the successor of a
328 <a href="#ref_commit">commit</a> could be one of its parents).
329</p>
330</dd>
331<dt>
332<a id="ref_changeset"></a>changeset
333</dt>
334<dd>
335<p>
336 BitKeeper/cvsps speak for "<a href="#ref_commit">commit</a>". Since git does not
337 store changes, but states, it really does not make sense to use the term
338 "changesets" with git.
339</p>
340</dd>
341<dt>
342<a id="ref_checkout"></a>checkout
343</dt>
344<dd>
345<p>
346 The action of updating the <a href="#ref_working_tree">working tree</a> to a
347 <a href="#ref_revision">revision</a> which was stored in the
348 <a href="#ref_object_database">object database</a>.
349</p>
350</dd>
351<dt>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]352<a id="ref_cherry-picking"></a>cherry-picking
353</dt>
354<dd>
355<p>
356 In <a href="#ref_SCM">SCM</a> jargon, "cherry pick" means to choose a subset of
357 changes out of a series of changes (typically commits) and record them
358 as a new series of changes on top of different codebase. In GIT, this is
359 performed by "git cherry-pick" command to extract the change introduced
360 by an existing <a href="#ref_commit">commit</a> and to record it based on the tip
361 of the current <a href="#ref_branch">branch</a> as a new <a href="#ref_commit">commit</a>.
362</p>
363</dd>
364<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]365<a id="ref_clean"></a>clean
366</dt>
367<dd>
368<p>
369 A <a href="#ref_working_tree">working tree</a> is <a href="#ref_clean">clean</a>, if it
370 corresponds to the <a href="#ref_revision">revision</a> referenced by the current
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]371 <a href="#ref_head">head</a>. Also see "<a href="#ref_dirty">dirty</a>".
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]372</p>
373</dd>
374<dt>
375<a id="ref_commit"></a>commit
376</dt>
377<dd>
378<p>
379 As a verb: The action of storing the current state of the
380 <a href="#ref_index">index</a> in the <a href="#ref_object_database">object database</a>. The
381 result is a <a href="#ref_revision">revision</a>. As a noun: Short hand for
382 <a href="#ref_commit_object">commit object</a>.
383</p>
384</dd>
385<dt>
386<a id="ref_commit_object"></a>commit object
387</dt>
388<dd>
389<p>
390 An <a href="#ref_object">object</a> which contains the information about a
391 particular <a href="#ref_revision">revision</a>, such as parents, committer,
392 author, date and the <a href="#ref_tree_object">tree object</a> which corresponds
393 to the top <a href="#ref_directory">directory</a> of the stored
394 <a href="#ref_revision">revision</a>.
395</p>
396</dd>
397<dt>
398<a id="ref_core_git"></a>core git
399</dt>
400<dd>
401<p>
402 Fundamental data structures and utilities of git. Exposes only limited
403 source code management tools.
404</p>
405</dd>
406<dt>
407<a id="ref_DAG"></a>DAG
408</dt>
409<dd>
410<p>
411 Directed acyclic graph. The <a href="#ref_commit">commit</a> objects form a
412 directed acyclic graph, because they have parents (directed), and the
413 graph of <a href="#ref_commit">commit</a> objects is acyclic (there is no
414 <a href="#ref_chain">chain</a> which begins and ends with the same
415 <a href="#ref_object">object</a>).
416</p>
417</dd>
418<dt>
419<a id="ref_dircache"></a>dircache
420</dt>
421<dd>
422<p>
423 You are <strong>waaaaay</strong> behind.
424</p>
425</dd>
426<dt>
427<a id="ref_directory"></a>directory
428</dt>
429<dd>
430<p>
431 The list you get with "ls" :-)
432</p>
433</dd>
434<dt>
435<a id="ref_dirty"></a>dirty
436</dt>
437<dd>
438<p>
439 A <a href="#ref_working_tree">working tree</a> is said to be <a href="#ref_dirty">dirty</a> if
440 it contains modifications which have not been committed to the current
441 <a href="#ref_branch">branch</a>.
442</p>
443</dd>
444<dt>
445<a id="ref_ent"></a>ent
446</dt>
447<dd>
448<p>
449 Favorite synonym to "<a href="#ref_tree-ish">tree-ish</a>" by some total geeks. See
450 <tt>http://en.wikipedia.org/wiki/Ent_(Middle-earth)</tt> for an in-depth
Junio C Hamano51c2ab02006-07-09 20:38:54[diff] [blame]451 explanation. Avoid this term, not to confuse people.
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]452</p>
453</dd>
454<dt>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]455<a id="ref_fast_forward"></a>fast forward
456</dt>
457<dd>
458<p>
459 A fast-forward is a special type of <a href="#ref_merge">merge</a> where you have a
460 <a href="#ref_revision">revision</a> and you are "merging" another
461 <a href="#ref_branch">branch</a>'s changes that happen to be a descendant of what
462 you have. In such these cases, you do not make a new <a href="#ref_merge">merge</a>
463 <a href="#ref_commit">commit</a> but instead just update to his
464 <a href="#ref_revision">revision</a>. This will happen frequently on a
465 <a href="#ref_tracking_branch">tracking branch</a> of a remote
466 <a href="#ref_repository">repository</a>.
467</p>
468</dd>
469<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]470<a id="ref_fetch"></a>fetch
471</dt>
472<dd>
473<p>
474 Fetching a <a href="#ref_branch">branch</a> means to get the
475 <a href="#ref_branch">branch</a>'s <a href="#ref_head_ref">head ref</a> from a remote
476 <a href="#ref_repository">repository</a>, to find out which objects are missing
477 from the local <a href="#ref_object_database">object database</a>, and to get them,
478 too.
479</p>
480</dd>
481<dt>
482<a id="ref_file_system"></a>file system
483</dt>
484<dd>
485<p>
486 Linus Torvalds originally designed git to be a user space file system,
487 i.e. the infrastructure to hold files and directories. That ensured the
488 efficiency and speed of git.
489</p>
490</dd>
491<dt>
492<a id="ref_git_archive"></a>git archive
493</dt>
494<dd>
495<p>
496 Synonym for <a href="#ref_repository">repository</a> (for arch people).
497</p>
498</dd>
499<dt>
Junio C Hamano33db4372006-06-07 19:51:45[diff] [blame]500<a id="ref_grafts"></a>grafts
501</dt>
502<dd>
503<p>
504 Grafts enables two otherwise different lines of development to be joined
505 together by recording fake ancestry information for commits. This way
506 you can make git pretend the set of parents a <a href="#ref_commit">commit</a> has
507 is different from what was recorded when the <a href="#ref_commit">commit</a> was
508 created. Configured via the <tt>.git/info/<a href="#ref_grafts">grafts</a></tt> file.
509</p>
510</dd>
511<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]512<a id="ref_hash"></a>hash
513</dt>
514<dd>
515<p>
516 In git's context, synonym to <a href="#ref_object_name">object name</a>.
517</p>
518</dd>
519<dt>
520<a id="ref_head"></a>head
521</dt>
522<dd>
523<p>
524 The top of a <a href="#ref_branch">branch</a>. It contains a <a href="#ref_ref">ref</a> to the
525 corresponding <a href="#ref_commit_object">commit object</a>.
526</p>
527</dd>
528<dt>
529<a id="ref_head_ref"></a>head ref
530</dt>
531<dd>
532<p>
533 A <a href="#ref_ref">ref</a> pointing to a <a href="#ref_head">head</a>. Often, this is
534 abbreviated to "<a href="#ref_head">head</a>". Head refs are stored in
535 <tt>$GIT_DIR/refs/heads/</tt>.
536</p>
537</dd>
538<dt>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]539<a id="ref_hook"></a>hook
540</dt>
541<dd>
542<p>
543 During the normal execution of several git commands, call-outs are made
544 to optional scripts that allow a developer to add functionality or
545 checking. Typically, the hooks allow for a command to be pre-verified
546 and potentially aborted, and allow for a post-notification after the
547 operation is done. The <a href="#ref_hook">hook</a> scripts are found in the
548 <tt>$GIT_DIR/hooks/</tt> <a href="#ref_directory">directory</a>, and are enabled by simply
549 making them executable.
550</p>
551</dd>
552<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]553<a id="ref_index"></a>index
554</dt>
555<dd>
556<p>
557 A collection of files with stat information, whose contents are stored
558 as objects. The <a href="#ref_index">index</a> is a stored version of your working
559 <a href="#ref_tree">tree</a>. Truth be told, it can also contain a second, and even
560 a third version of a <a href="#ref_working_tree">working tree</a>, which are used
561 when merging.
562</p>
563</dd>
564<dt>
565<a id="ref_index_entry"></a>index entry
566</dt>
567<dd>
568<p>
569 The information regarding a particular file, stored in the
570 <a href="#ref_index">index</a>. An <a href="#ref_index_entry">index entry</a> can be unmerged,
571 if a <a href="#ref_merge">merge</a> was started, but not yet finished (i.e. if the
572 <a href="#ref_index">index</a> contains multiple versions of that file).
573</p>
574</dd>
575<dt>
Junio C Hamanof3e80c02006-01-11 00:54:55[diff] [blame]576<a id="ref_master"></a>master
577</dt>
578<dd>
579<p>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]580 The default development <a href="#ref_branch">branch</a>. Whenever you create a git
Junio C Hamanof3e80c02006-01-11 00:54:55[diff] [blame]581 <a href="#ref_repository">repository</a>, a <a href="#ref_branch">branch</a> named
582 "<a href="#ref_master">master</a>" is created, and becomes the active
583 <a href="#ref_branch">branch</a>. In most cases, this contains the local
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]584 development, though that is purely conventional and not required.
Junio C Hamanof3e80c02006-01-11 00:54:55[diff] [blame]585</p>
586</dd>
587<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]588<a id="ref_merge"></a>merge
589</dt>
590<dd>
591<p>
592 To <a href="#ref_merge">merge</a> branches means to try to accumulate the changes
593 since a common ancestor and apply them to the first
594 <a href="#ref_branch">branch</a>. An automatic <a href="#ref_merge">merge</a> uses heuristics
595 to accomplish that. Evidently, an automatic <a href="#ref_merge">merge</a> can
596 fail.
597</p>
598</dd>
599<dt>
600<a id="ref_object"></a>object
601</dt>
602<dd>
603<p>
604 The unit of storage in git. It is uniquely identified by the
605 <a href="#ref_SHA1">SHA1</a> of its contents. Consequently, an
606 <a href="#ref_object">object</a> can not be changed.
607</p>
608</dd>
609<dt>
610<a id="ref_object_database"></a>object database
611</dt>
612<dd>
613<p>
Junio C Hamano235a91e2006-01-07 01:13:58[diff] [blame]614 Stores a set of "objects", and an individual <a href="#ref_object">object</a> is
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]615 identified by its <a href="#ref_object_name">object name</a>. The objects usually
616 live in <tt>$GIT_DIR/objects/</tt>.
617</p>
618</dd>
619<dt>
620<a id="ref_object_identifier"></a>object identifier
621</dt>
622<dd>
623<p>
624 Synonym for <a href="#ref_object_name">object name</a>.
625</p>
626</dd>
627<dt>
628<a id="ref_object_name"></a>object name
629</dt>
630<dd>
631<p>
632 The unique identifier of an <a href="#ref_object">object</a>. The <a href="#ref_hash">hash</a>
633 of the <a href="#ref_object">object</a>'s contents using the Secure Hash Algorithm
634 1 and usually represented by the 40 character hexadecimal encoding of
635 the <a href="#ref_hash">hash</a> of the <a href="#ref_object">object</a> (possibly followed by
636 a white space).
637</p>
638</dd>
639<dt>
Junio C Hamano21c0b422006-10-12 19:10:36[diff] [blame]640<a id="ref_object_type"></a>object type
641</dt>
642<dd>
643<p>
644 One of the identifiers
645 "<a href="#ref_commit">commit</a>","<a href="#ref_tree">tree</a>","<a href="#ref_tag">tag</a>" and "blob"
646 describing the type of an <a href="#ref_object">object</a>.
647</p>
648</dd>
649<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]650<a id="ref_octopus"></a>octopus
651</dt>
652<dd>
653<p>
654 To <a href="#ref_merge">merge</a> more than two branches. Also denotes an
655 intelligent predator.
656</p>
657</dd>
658<dt>
Junio C Hamanof3e80c02006-01-11 00:54:55[diff] [blame]659<a id="ref_origin"></a>origin
660</dt>
661<dd>
662<p>
Junio C Hamanod3361ad2007-01-01 03:20:24[diff] [blame]663 The default upstream <a href="#ref_repository">repository</a>. Most projects have
664 at least one upstream project which they track. By default
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]665 <em><a href="#ref_origin">origin</a></em> is used for that purpose. New upstream updates
Junio C Hamanod3361ad2007-01-01 03:20:24[diff] [blame]666 will be fetched into remote tracking branches named
667 <a href="#ref_origin">origin</a>/name-of-upstream-<a href="#ref_branch">branch</a>, which you
668 can see using "git <a href="#ref_branch">branch</a> -r".
Junio C Hamanof3e80c02006-01-11 00:54:55[diff] [blame]669</p>
670</dd>
671<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]672<a id="ref_pack"></a>pack
673</dt>
674<dd>
675<p>
676 A set of objects which have been compressed into one file (to save space
677 or to transmit them efficiently).
678</p>
679</dd>
680<dt>
681<a id="ref_pack_index"></a>pack index
682</dt>
683<dd>
684<p>
685 The list of identifiers, and other information, of the objects in a
686 <a href="#ref_pack">pack</a>, to assist in efficiently accessing the contents of a
687 <a href="#ref_pack">pack</a>.
688</p>
689</dd>
690<dt>
691<a id="ref_parent"></a>parent
692</dt>
693<dd>
694<p>
695 A <a href="#ref_commit_object">commit object</a> contains a (possibly empty) list
696 of the logical predecessor(s) in the line of development, i.e. its
697 parents.
698</p>
699</dd>
700<dt>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]701<a id="ref_pickaxe"></a>pickaxe
702</dt>
703<dd>
704<p>
705 The term <a href="#ref_pickaxe">pickaxe</a> refers to an option to the diffcore
706 routines that help select changes that add or delete a given text
707 string. With the &#8212;<a href="#ref_pickaxe">pickaxe</a>-all option, it can be used to
708 view the full <a href="#ref_changeset">changeset</a> that introduced or removed,
709 say, a particular line of text. See <a href="git-diff.html">git-diff(1)</a>.
710</p>
711</dd>
712<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]713<a id="ref_plumbing"></a>plumbing
714</dt>
715<dd>
716<p>
717 Cute name for <a href="#ref_core_git">core git</a>.
718</p>
719</dd>
720<dt>
721<a id="ref_porcelain"></a>porcelain
722</dt>
723<dd>
724<p>
725 Cute name for programs and program suites depending on
726 <a href="#ref_core_git">core git</a>, presenting a high level access to
727 <a href="#ref_core_git">core git</a>. Porcelains expose more of a <a href="#ref_SCM">SCM</a>
728 interface than the <a href="#ref_plumbing">plumbing</a>.
729</p>
730</dd>
731<dt>
732<a id="ref_pull"></a>pull
733</dt>
734<dd>
735<p>
736 Pulling a <a href="#ref_branch">branch</a> means to <a href="#ref_fetch">fetch</a> it and
737 <a href="#ref_merge">merge</a> it.
738</p>
739</dd>
740<dt>
741<a id="ref_push"></a>push
742</dt>
743<dd>
744<p>
745 Pushing a <a href="#ref_branch">branch</a> means to get the <a href="#ref_branch">branch</a>'s
746 <a href="#ref_head_ref">head ref</a> from a remote <a href="#ref_repository">repository</a>,
747 find out if it is an ancestor to the <a href="#ref_branch">branch</a>'s local
748 <a href="#ref_head_ref">head ref</a> is a direct, and in that case, putting all
749 objects, which are <a href="#ref_reachable">reachable</a> from the local
750 <a href="#ref_head_ref">head ref</a>, and which are missing from the remote
751 <a href="#ref_repository">repository</a>, into the remote
752 <a href="#ref_object_database">object database</a>, and updating the remote
753 <a href="#ref_head_ref">head ref</a>. If the remote <a href="#ref_head">head</a> is not an
754 ancestor to the local <a href="#ref_head">head</a>, the <a href="#ref_push">push</a> fails.
755</p>
756</dd>
757<dt>
758<a id="ref_reachable"></a>reachable
759</dt>
760<dd>
761<p>
762 An <a href="#ref_object">object</a> is <a href="#ref_reachable">reachable</a> from a
763 <a href="#ref_ref">ref</a>/<a href="#ref_commit">commit</a>/<a href="#ref_tree">tree</a>/<a href="#ref_tag">tag</a>,
764 if there is a <a href="#ref_chain">chain</a> leading from the latter to the former.
765</p>
766</dd>
767<dt>
768<a id="ref_rebase"></a>rebase
769</dt>
770<dd>
771<p>
772 To <a href="#ref_clean">clean</a> a <a href="#ref_branch">branch</a> by starting from the
Junio C Hamanof3e80c02006-01-11 00:54:55[diff] [blame]773 <a href="#ref_head">head</a> of the main line of development
774 ("<a href="#ref_master">master</a>"), and reapply the (possibly cherry-picked)
775 changes from that <a href="#ref_branch">branch</a>.
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]776</p>
777</dd>
778<dt>
779<a id="ref_ref"></a>ref
780</dt>
781<dd>
782<p>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]783 A 40-byte hex representation of a <a href="#ref_SHA1">SHA1</a> or a name that
784 denotes a particular <a href="#ref_object">object</a>. These may be stored in
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]785 <tt>$GIT_DIR/refs/</tt>.
786</p>
787</dd>
788<dt>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]789<a id="ref_refspec"></a>refspec
790</dt>
791<dd>
792<p>
793 A <a href="#ref_refspec">refspec</a> is used by <a href="#ref_fetch">fetch</a> and
794 <a href="#ref_push">push</a> to describe the mapping between remote <a href="#ref_ref">ref</a>
795 and local <a href="#ref_ref">ref</a>. They are combined with a colon in the format
796 &lt;src&gt;:&lt;dst&gt;, preceded by an optional plus sign, +. For example: <tt>git
797 <a href="#ref_fetch">fetch</a> $URL
798 refs/heads/<a href="#ref_master">master</a>:refs/heads/<a href="#ref_origin">origin</a></tt> means
799 "grab the <a href="#ref_master">master</a> <a href="#ref_branch">branch</a> <a href="#ref_head">head</a>
800 from the $URL and store it as my <a href="#ref_origin">origin</a>
801 <a href="#ref_branch">branch</a> <a href="#ref_head">head</a>". And <tt>git <a href="#ref_push">push</a>
802 $URL refs/heads/<a href="#ref_master">master</a>:refs/heads/to-upstream</tt> means
803 "publish my <a href="#ref_master">master</a> <a href="#ref_branch">branch</a>
804 <a href="#ref_head">head</a> as to-upstream <a href="#ref_master">master</a> <a href="#ref_head">head</a>
805 at $URL". See also <a href="git-push.html">git-push(1)</a>
806</p>
807</dd>
808<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]809<a id="ref_repository"></a>repository
810</dt>
811<dd>
812<p>
813 A collection of refs together with an <a href="#ref_object_database">object database</a> containing all objects, which are <a href="#ref_reachable">reachable</a>
814 from the refs, possibly accompanied by meta data from one or more
815 porcelains. A <a href="#ref_repository">repository</a> can share an
816 <a href="#ref_object_database">object database</a> with other repositories.
817</p>
818</dd>
819<dt>
820<a id="ref_resolve"></a>resolve
821</dt>
822<dd>
823<p>
824 The action of fixing up manually what a failed automatic
825 <a href="#ref_merge">merge</a> left behind.
826</p>
827</dd>
828<dt>
829<a id="ref_revision"></a>revision
830</dt>
831<dd>
832<p>
833 A particular state of files and directories which was stored in the
834 <a href="#ref_object_database">object database</a>. It is referenced by a
835 <a href="#ref_commit_object">commit object</a>.
836</p>
837</dd>
838<dt>
839<a id="ref_rewind"></a>rewind
840</dt>
841<dd>
842<p>
843 To throw away part of the development, i.e. to assign the
844 <a href="#ref_head">head</a> to an earlier <a href="#ref_revision">revision</a>.
845</p>
846</dd>
847<dt>
848<a id="ref_SCM"></a>SCM
849</dt>
850<dd>
851<p>
852 Source code management (tool).
853</p>
854</dd>
855<dt>
856<a id="ref_SHA1"></a>SHA1
857</dt>
858<dd>
859<p>
860 Synonym for <a href="#ref_object_name">object name</a>.
861</p>
862</dd>
863<dt>
Junio C Hamano3a971022006-11-18 22:17:58[diff] [blame]864<a id="ref_symref"></a>symref
865</dt>
866<dd>
867<p>
868 Symbolic reference: instead of containing the <a href="#ref_SHA1">SHA1</a> id
869 itself, it is of the format <em><a href="#ref_ref">ref</a>: refs/some/thing</em> and when
870 referenced, it recursively dereferences to this reference. <em>HEAD</em> is a
871 prime example of a <a href="#ref_symref">symref</a>. Symbolic references are
872 manipulated with the <a href="git-symbolic-<a href="#ref_ref">ref</a>.html">git-symbolic-<a href="#ref_ref">ref</a>(1)</a> command.
873</p>
874</dd>
875<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]876<a id="ref_tag"></a>tag
877</dt>
878<dd>
879<p>
880 A <a href="#ref_ref">ref</a> pointing to a <a href="#ref_tag">tag</a> or
881 <a href="#ref_commit_object">commit object</a>. In contrast to a <a href="#ref_head">head</a>,
882 a <a href="#ref_tag">tag</a> is not changed by a <a href="#ref_commit">commit</a>. Tags (not
883 <a href="#ref_tag">tag</a> objects) are stored in <tt>$GIT_DIR/refs/tags/</tt>. A git
884 <a href="#ref_tag">tag</a> has nothing to do with a Lisp <a href="#ref_tag">tag</a> (which is
Junio C Hamano21c0b422006-10-12 19:10:36[diff] [blame]885 called <a href="#ref_object_type">object type</a> in git's context). A
886 <a href="#ref_tag">tag</a> is most typically used to mark a particular point in the
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]887 <a href="#ref_commit">commit</a> ancestry <a href="#ref_chain">chain</a>.
888</p>
889</dd>
890<dt>
891<a id="ref_tag_object"></a>tag object
892</dt>
893<dd>
894<p>
895 An <a href="#ref_object">object</a> containing a <a href="#ref_ref">ref</a> pointing to
896 another <a href="#ref_object">object</a>, which can contain a message just like a
897 <a href="#ref_commit_object">commit object</a>. It can also contain a (PGP)
898 signature, in which case it is called a "signed <a href="#ref_tag_object">tag object</a>".
899</p>
900</dd>
901<dt>
Junio C Hamano88a3a072006-05-04 08:01:43[diff] [blame]902<a id="ref_topic_branch"></a>topic branch
903</dt>
904<dd>
905<p>
906 A regular git <a href="#ref_branch">branch</a> that is used by a developer to
907 identify a conceptual line of development. Since branches are very easy
908 and inexpensive, it is often desirable to have several small branches
909 that each contain very well defined concepts or small incremental yet
910 related changes.
911</p>
912</dd>
913<dt>
914<a id="ref_tracking_branch"></a>tracking branch
915</dt>
916<dd>
917<p>
918 A regular git <a href="#ref_branch">branch</a> that is used to follow changes from
919 another <a href="#ref_repository">repository</a>. A <a href="#ref_tracking_branch">tracking branch</a> should not contain direct modifications or have local commits
920 made to it. A <a href="#ref_tracking_branch">tracking branch</a> can usually be
921 identified as the right-hand-side <a href="#ref_ref">ref</a> in a Pull:
922 <a href="#ref_refspec">refspec</a>.
923</p>
924</dd>
925<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]926<a id="ref_tree"></a>tree
927</dt>
928<dd>
929<p>
930 Either a <a href="#ref_working_tree">working tree</a>, or a <a href="#ref_tree_object">tree object</a> together with the dependent blob and <a href="#ref_tree">tree</a> objects
931 (i.e. a stored representation of a <a href="#ref_working_tree">working tree</a>).
932</p>
933</dd>
934<dt>
935<a id="ref_tree_object"></a>tree object
936</dt>
937<dd>
938<p>
939 An <a href="#ref_object">object</a> containing a list of file names and modes along
940 with refs to the associated blob and/or <a href="#ref_tree">tree</a> objects. A
941 <a href="#ref_tree">tree</a> is equivalent to a <a href="#ref_directory">directory</a>.
942</p>
943</dd>
944<dt>
945<a id="ref_tree-ish"></a>tree-ish
946</dt>
947<dd>
948<p>
949 A <a href="#ref_ref">ref</a> pointing to either a <a href="#ref_commit_object">commit object</a>, a <a href="#ref_tree_object">tree object</a>, or a <a href="#ref_tag_object">tag object</a> pointing to a <a href="#ref_tag">tag</a> or <a href="#ref_commit">commit</a> or
950 <a href="#ref_tree_object">tree object</a>.
951</p>
952</dd>
953<dt>
Junio C Hamano21c0b422006-10-12 19:10:36[diff] [blame]954<a id="ref_unmerged_index"></a>unmerged index
955</dt>
956<dd>
957<p>
958 An <a href="#ref_index">index</a> which contains <a href="#ref_unmerged_index">unmerged index</a> entries.
959</p>
960</dd>
961<dt>
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]962<a id="ref_working_tree"></a>working tree
963</dt>
964<dd>
965<p>
966 The set of files and directories currently being worked on, i.e. you can
967 work in your <a href="#ref_working_tree">working tree</a> without using git at all.
968</p>
969</dd>
970</dl>
971</div>
972</div>
973<h2>Author</h2>
974<div class="sectionbody">
975<p>Written by Johannes Schindelin &lt;Johannes.Schindelin@gmx.de&gt; and
976the git-list &lt;git@vger.kernel.org&gt;.</p>
977</div>
978<h2>GIT</h2>
979<div class="sectionbody">
980<p>Part of the <a href="git.html">git</a> suite</p>
981</div>
982<div id="footer">
983<div id="footer-text">
Junio C Hamanod3361ad2007-01-01 03:20:24[diff] [blame]984Last updated 01-Jan-2007 03:20:17 UTC
Junio C Hamano1a4e8412005-12-27 08:17:23[diff] [blame]985</div>
986</div>
987</body>
988</html>