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