@@ -13,7 +13,7 @@ GIT Glossary
13
13
<<def_revision,revision>> control. That is, all of the `git`
14
14
administrative and control files that would normally be present in the
15
15
hidden `.git` sub-directory are directly present in the
16
- `<<def_repository, repository>> .git` <<def_directory, directory>> instead,
16
+ `repository.git` directory instead,
17
17
and no other files are present and checked out. Usually publishers of
18
18
public repositories make bare repositories available.
19
19
@@ -23,7 +23,7 @@ GIT Glossary
23
23
[[def_branch]]branch::
24
24
A non-cyclical graph of revisions, i.e. the complete history of a
25
25
particular <<def_revision,revision>>, which is called the
26
- <<def_branch, branch>> <<def_head,head>>. The <<def_branch,branch>> heads
26
+ branch <<def_head,head>>. The heads
27
27
are stored in `$GIT_DIR/refs/heads/`.
28
28
29
29
[[def_cache]]cache::
@@ -133,7 +133,7 @@ GIT Glossary
133
133
together by recording fake ancestry information for commits. This way
134
134
you can make git pretend the set of parents a <<def_commit,commit>> has
135
135
is different from what was recorded when the <<def_commit,commit>> was
136
- created. Configured via the `.git/info/<<def_grafts, grafts>> ` file.
136
+ created. Configured via the `.git/info/grafts` file.
137
137
138
138
[[def_hash]]hash::
139
139
In git's context, synonym to <<def_object_name,object name>>.
@@ -205,7 +205,7 @@ GIT Glossary
205
205
206
206
[[def_object_type]]object type::
207
207
One of the identifiers
208
- "<<def_commit,commit>>","<<def_tree,tree>>","<<def_tag,tag>>" and " blob"
208
+ "<<def_commit,commit>>","<<def_tree,tree>>","<<def_tag,tag>>" or "<<def_blob_object, blob>> "
209
209
describing the type of an <<def_object,object>>.
210
210
211
211
[[def_octopus]]octopus::
@@ -217,7 +217,7 @@ GIT Glossary
217
217
at least one upstream project which they track. By default
218
218
'<<def_origin,origin>>' is used for that purpose. New upstream updates
219
219
will be fetched into remote tracking branches named
220
- <<def_origin, origin>> /name-of-upstream-branch, which you can see using
220
+ origin/name-of-upstream-branch, which you can see using
221
221
"git <<def_branch,branch>> -r".
222
222
223
223
[[def_pack]]pack::
@@ -271,14 +271,15 @@ GIT Glossary
271
271
<<def_reachable,reachable>> from that <<def_commit,commit>>. More
272
272
generally, one <<def_object,object>> is <<def_reachable,reachable>> from
273
273
another if we can reach the one from the other by a <<def_chain,chain>>
274
- that follows tags to whatever they <<def_tag,tag>>, commits to their
275
- parents or trees, and trees to the trees or blobs that they contain.
274
+ that follows <<def_tag,tags>> to whatever they tag,
275
+ <<def_commit_object,commits>> to their parents or trees, and
276
+ <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>>
277
+ that they contain.
276
278
277
279
[[def_rebase]]rebase::
278
- To <<def_clean,clean>> a <<def_branch,branch>> by starting from the
279
- <<def_head,head>> of the main line of development
280
- ("<<def_master,master>>"), and reapply the (possibly cherry-picked)
281
- changes from that <<def_branch,branch>>.
280
+ To reapply a series of changes from a <<def_branch,branch>> to a
281
+ different base, and reset the <<def_head,head>> of that branch
282
+ to the result.
282
283
283
284
[[def_ref]]ref::
284
285
A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that
@@ -290,19 +291,18 @@ GIT Glossary
290
291
<<def_push,push>> to describe the mapping between remote <<def_ref,ref>>
291
292
and local <<def_ref,ref>>. They are combined with a colon in the format
292
293
<src>:<dst>, preceded by an optional plus sign, +. For example: `git
293
- <<def_fetch,fetch>> $URL
294
- refs/heads/<<def_master,master>>:refs/heads/<<def_origin,origin>>` means
295
- "grab the <<def_master,master>> <<def_branch,branch>> <<def_head,head>>
296
- from the $URL and store it as my <<def_origin,origin>>
294
+ fetch $URL refs/heads/master:refs/heads/origin` means
295
+ "grab the master <<def_branch,branch>> <<def_head,head>>
296
+ from the $URL and store it as my origin
297
297
<<def_branch,branch>> <<def_head,head>>". And `git <<def_push,push>>
298
- $URL refs/heads/<<def_master, master>> :refs/heads/to-upstream` means
299
- "publish my <<def_master, master>> <<def_branch,branch>>
298
+ $URL refs/heads/master:refs/heads/to-upstream` means
299
+ "publish my master <<def_branch,branch>>
300
300
<<def_head,head>> as to-upstream <<def_branch,branch>> at $URL". See
301
301
also gitlink:git-push[1]
302
302
303
303
[[def_repository]]repository::
304
304
A collection of refs together with an <<def_object_database,object
305
- database>> containing all objects, which are <<def_reachable,reachable>>
305
+ database>> containing all objects which are <<def_reachable,reachable>>
306
306
from the refs, possibly accompanied by meta data from one or more
307
307
porcelains. A <<def_repository,repository>> can share an
308
308
<<def_object_database,object database>> with other repositories.
@@ -334,24 +334,24 @@ GIT Glossary
334
334
object>>). This is sometimes useful when you are interested only in the
335
335
recent history of a project even though the real history recorded in the
336
336
upstream is much larger. A <<def_shallow_repository,shallow repository>>
337
- is created by giving `--depth` option to gitlink:git-clone[1], and its
338
- history can be later deepened with gitlink:git-fetch[1].
337
+ is created by giving the `--depth` option to gitlink:git-clone[1], and
338
+ its history can be later deepened with gitlink:git-fetch[1].
339
339
340
340
[[def_symref]]symref::
341
341
Symbolic reference: instead of containing the <<def_SHA1,SHA1>> id
342
- itself, it is of the format '<<def_ref, ref>> : refs/some/thing' and when
342
+ itself, it is of the format 'ref: refs/some/thing' and when
343
343
referenced, it recursively dereferences to this reference. 'HEAD' is a
344
344
prime example of a <<def_symref,symref>>. Symbolic references are
345
345
manipulated with the gitlink:git-symbolic-ref[1] command.
346
346
347
347
[[def_tag]]tag::
348
348
A <<def_ref,ref>> pointing to a <<def_tag,tag>> or
349
349
<<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
350
- a <<def_tag, tag>> is not changed by a <<def_commit,commit>>. Tags (not
351
- <<def_tag ,tag>> objects) are stored in `$GIT_DIR/refs/tags/`. A git
352
- <<def_tag, tag>> has nothing to do with a Lisp <<def_tag, tag>> (which is
353
- called <<def_object_type,object type>> in git's context). A
354
- <<def_tag, tag>> is most typically used to mark a particular point in the
350
+ a tag is not changed by a <<def_commit,commit>>. Tags (not
351
+ <<def_tag_object ,tag objects>> ) are stored in `$GIT_DIR/refs/tags/`. A
352
+ git tag has nothing to do with a Lisp tag (which would be
353
+ called an <<def_object_type,object type>> in git's context). A
354
+ tag is most typically used to mark a particular point in the
355
355
<<def_commit,commit>> ancestry <<def_chain,chain>>.
356
356
357
357
[[def_tag_object]]tag object::
@@ -383,7 +383,7 @@ GIT Glossary
383
383
384
384
[[def_tree_object]]tree object::
385
385
An <<def_object,object>> containing a list of file names and modes along
386
- with refs to the associated blob and/or <<def_tree, tree>> objects. A
386
+ with refs to the associated blob and/or tree objects. A
387
387
<<def_tree,tree>> is equivalent to a <<def_directory,directory>>.
388
388
389
389
[[def_tree-ish]]tree-ish::
@@ -393,8 +393,8 @@ GIT Glossary
393
393
<<def_tree_object,tree object>>.
394
394
395
395
[[def_unmerged_index]]unmerged index::
396
- An <<def_index,index>> which contains <<def_unmerged_index, unmerged
397
- index>> entries.
396
+ An <<def_index,index>> which contains unmerged
397
+ <<def_index_entry, index entries>> .
398
398
399
399
[[def_unreachable_object]]unreachable object::
400
400
An <<def_object,object>> which is not <<def_reachable,reachable>> from a
0 commit comments