]>
Commit | Line | Data |
---|---|---|
f562e6f3 BF |
1 | GIT Glossary |
2 | ============ | |
3 | ||
4 | [[def_alternate_object_database]]alternate object database:: | |
343cad92 BF |
5 | Via the alternates mechanism, a <<def_repository,repository>> |
6 | can inherit part of its <<def_object_database,object database>> | |
7 | from another object database, which is called "alternate". | |
f562e6f3 BF |
8 | |
9 | [[def_bare_repository]]bare repository:: | |
343cad92 | 10 | A bare repository is normally an appropriately |
f562e6f3 BF |
11 | named <<def_directory,directory>> with a `.git` suffix that does not |
12 | have a locally checked-out copy of any of the files under | |
a58f3c01 | 13 | revision control. That is, all of the `git` |
f562e6f3 BF |
14 | administrative and control files that would normally be present in the |
15 | hidden `.git` sub-directory are directly present in the | |
cbd91922 | 16 | `repository.git` directory instead, |
f562e6f3 BF |
17 | and no other files are present and checked out. Usually publishers of |
18 | public repositories make bare repositories available. | |
19 | ||
20 | [[def_blob_object]]blob object:: | |
21 | Untyped <<def_object,object>>, e.g. the contents of a file. | |
22 | ||
23 | [[def_branch]]branch:: | |
343cad92 BF |
24 | A "branch" is an active line of development. The most recent |
25 | <<def_commit,commit>> on a branch is referred to as the tip of | |
26 | that branch. The tip of the branch is referenced by a branch | |
27 | <<def_head,head>>, which moves forward as additional development | |
28 | is done on the branch. A single git | |
29 | <<def_repository,repository>> can track an arbitrary number of | |
30 | branches, but your <<def_working_tree,working tree>> is | |
31 | associated with just one of them (the "current" or "checked out" | |
32 | branch), and <<def_HEAD,HEAD>> points to that branch. | |
f562e6f3 BF |
33 | |
34 | [[def_cache]]cache:: | |
35 | Obsolete for: <<def_index,index>>. | |
36 | ||
37 | [[def_chain]]chain:: | |
38 | A list of objects, where each <<def_object,object>> in the list contains | |
39 | a reference to its successor (for example, the successor of a | |
a58f3c01 | 40 | <<def_commit,commit>> could be one of its <<def_parent,parents>>). |
f562e6f3 BF |
41 | |
42 | [[def_changeset]]changeset:: | |
43 | BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not | |
44 | store changes, but states, it really does not make sense to use the term | |
45 | "changesets" with git. | |
46 | ||
47 | [[def_checkout]]checkout:: | |
48 | The action of updating the <<def_working_tree,working tree>> to a | |
49 | <<def_revision,revision>> which was stored in the | |
50 | <<def_object_database,object database>>. | |
51 | ||
52 | [[def_cherry-picking]]cherry-picking:: | |
53 | In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of | |
54 | changes out of a series of changes (typically commits) and record them | |
55 | as a new series of changes on top of different codebase. In GIT, this is | |
56 | performed by "git cherry-pick" command to extract the change introduced | |
57 | by an existing <<def_commit,commit>> and to record it based on the tip | |
343cad92 | 58 | of the current <<def_branch,branch>> as a new commit. |
f562e6f3 BF |
59 | |
60 | [[def_clean]]clean:: | |
343cad92 | 61 | A <<def_working_tree,working tree>> is clean, if it |
f562e6f3 BF |
62 | corresponds to the <<def_revision,revision>> referenced by the current |
63 | <<def_head,head>>. Also see "<<def_dirty,dirty>>". | |
64 | ||
65 | [[def_commit]]commit:: | |
343cad92 BF |
66 | As a noun: A single point in the |
67 | git history; the entire history of a project is represented as a | |
68 | set of interrelated commits. The word "commit" is often | |
69 | used by git in the same places other revision control systems | |
70 | use the words "revision" or "version". Also used as a short | |
71 | hand for <<def_commit_object,commit object>>. | |
72 | + | |
73 | As a verb: The action of storing a new snapshot of the project's | |
74 | state in the git history, by creating a new commit representing the current | |
75 | state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> | |
76 | to point at the new commit. | |
f562e6f3 BF |
77 | |
78 | [[def_commit_object]]commit object:: | |
79 | An <<def_object,object>> which contains the information about a | |
a58f3c01 | 80 | particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer, |
f562e6f3 BF |
81 | author, date and the <<def_tree_object,tree object>> which corresponds |
82 | to the top <<def_directory,directory>> of the stored | |
a58f3c01 | 83 | revision. |
f562e6f3 BF |
84 | |
85 | [[def_core_git]]core git:: | |
86 | Fundamental data structures and utilities of git. Exposes only limited | |
87 | source code management tools. | |
88 | ||
89 | [[def_DAG]]DAG:: | |
90 | Directed acyclic graph. The <<def_commit,commit>> objects form a | |
91 | directed acyclic graph, because they have parents (directed), and the | |
343cad92 | 92 | graph of commit objects is acyclic (there is no |
f562e6f3 BF |
93 | <<def_chain,chain>> which begins and ends with the same |
94 | <<def_object,object>>). | |
95 | ||
96 | [[def_dangling_object]]dangling object:: | |
97 | An <<def_unreachable_object,unreachable object>> which is not | |
98 | <<def_reachable,reachable>> even from other unreachable objects; a | |
343cad92 | 99 | dangling object has no references to it from any |
f562e6f3 BF |
100 | reference or <<def_object,object>> in the <<def_repository,repository>>. |
101 | ||
343cad92 BF |
102 | [[def_detached_HEAD]]detached HEAD:: |
103 | Normally the <<def_HEAD,HEAD>> stores the name of a | |
a58f3c01 JN |
104 | <<def_branch,branch>>. However, git also allows you to <<def_checkout,check out>> |
105 | an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any | |
343cad92 BF |
106 | particular branch. In this case HEAD is said to be "detached". |
107 | ||
f562e6f3 | 108 | [[def_dircache]]dircache:: |
a58f3c01 | 109 | You are *waaaaay* behind. See <<def_index,index>>. |
da139813 | 110 | |
f562e6f3 | 111 | [[def_directory]]directory:: |
aa9b1573 | 112 | The list you get with "ls" :-) |
da139813 | 113 | |
f562e6f3 | 114 | [[def_dirty]]dirty:: |
343cad92 | 115 | A <<def_working_tree,working tree>> is said to be "dirty" if |
a58f3c01 | 116 | it contains modifications which have not been <<def_commit,committed>> to the current |
f562e6f3 BF |
117 | <<def_branch,branch>>. |
118 | ||
119 | [[def_ent]]ent:: | |
120 | Favorite synonym to "<<def_tree-ish,tree-ish>>" by some total geeks. See | |
aa9b1573 | 121 | `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth |
f562e6f3 BF |
122 | explanation. Avoid this term, not to confuse people. |
123 | ||
c1bab288 JN |
124 | [[def_evil_merge]]evil merge:: |
125 | An evil merge is a <<def_merge,merge>> that introduces changes that | |
126 | do not appear in any <<def_parent,parent>>. | |
127 | ||
f562e6f3 BF |
128 | [[def_fast_forward]]fast forward:: |
129 | A fast-forward is a special type of <<def_merge,merge>> where you have a | |
130 | <<def_revision,revision>> and you are "merging" another | |
131 | <<def_branch,branch>>'s changes that happen to be a descendant of what | |
132 | you have. In such these cases, you do not make a new <<def_merge,merge>> | |
133 | <<def_commit,commit>> but instead just update to his | |
343cad92 | 134 | revision. This will happen frequently on a |
f562e6f3 BF |
135 | <<def_tracking_branch,tracking branch>> of a remote |
136 | <<def_repository,repository>>. | |
137 | ||
138 | [[def_fetch]]fetch:: | |
139 | Fetching a <<def_branch,branch>> means to get the | |
343cad92 BF |
140 | branch's <<def_head_ref,head ref>> from a remote |
141 | <<def_repository,repository>>, to find out which objects are | |
142 | missing from the local <<def_object_database,object database>>, | |
143 | and to get them, too. See also gitlink:git-fetch[1]. | |
f562e6f3 BF |
144 | |
145 | [[def_file_system]]file system:: | |
146 | Linus Torvalds originally designed git to be a user space file system, | |
147 | i.e. the infrastructure to hold files and directories. That ensured the | |
148 | efficiency and speed of git. | |
149 | ||
150 | [[def_git_archive]]git archive:: | |
151 | Synonym for <<def_repository,repository>> (for arch people). | |
152 | ||
153 | [[def_grafts]]grafts:: | |
154 | Grafts enables two otherwise different lines of development to be joined | |
155 | together by recording fake ancestry information for commits. This way | |
a58f3c01 | 156 | you can make git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has |
343cad92 | 157 | is different from what was recorded when the commit was |
cbd91922 | 158 | created. Configured via the `.git/info/grafts` file. |
f562e6f3 BF |
159 | |
160 | [[def_hash]]hash:: | |
161 | In git's context, synonym to <<def_object_name,object name>>. | |
162 | ||
163 | [[def_head]]head:: | |
a58f3c01 | 164 | A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a |
343cad92 BF |
165 | <<def_branch,branch>>. Heads are stored in |
166 | `$GIT_DIR/refs/heads/`, except when using packed refs. (See | |
167 | gitlink:git-pack-refs[1].) | |
168 | ||
169 | [[def_HEAD]]HEAD:: | |
a58f3c01 | 170 | The current <<def_branch,branch>>. In more detail: Your <<def_working_tree, |
343cad92 BF |
171 | working tree>> is normally derived from the state of the tree |
172 | referred to by HEAD. HEAD is a reference to one of the | |
173 | <<def_head,heads>> in your repository, except when using a | |
174 | <<def_detached_HEAD,detached HEAD>>, in which case it may | |
175 | reference an arbitrary commit. | |
f562e6f3 BF |
176 | |
177 | [[def_head_ref]]head ref:: | |
343cad92 | 178 | A synonym for <<def_head,head>>. |
f562e6f3 BF |
179 | |
180 | [[def_hook]]hook:: | |
181 | During the normal execution of several git commands, call-outs are made | |
182 | to optional scripts that allow a developer to add functionality or | |
183 | checking. Typically, the hooks allow for a command to be pre-verified | |
184 | and potentially aborted, and allow for a post-notification after the | |
343cad92 | 185 | operation is done. The hook scripts are found in the |
a58f3c01 | 186 | `$GIT_DIR/hooks/` directory, and are enabled by simply |
f562e6f3 BF |
187 | making them executable. |
188 | ||
189 | [[def_index]]index:: | |
190 | A collection of files with stat information, whose contents are stored | |
a58f3c01 JN |
191 | as objects. The index is a stored version of your |
192 | <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even | |
193 | a third version of a working tree, which are used | |
194 | when <<def_merge,merging>>. | |
f562e6f3 BF |
195 | |
196 | [[def_index_entry]]index entry:: | |
197 | The information regarding a particular file, stored in the | |
343cad92 BF |
198 | <<def_index,index>>. An index entry can be unmerged, if a |
199 | <<def_merge,merge>> was started, but not yet finished (i.e. if | |
200 | the index contains multiple versions of that file). | |
f562e6f3 BF |
201 | |
202 | [[def_master]]master:: | |
343cad92 BF |
203 | The default development <<def_branch,branch>>. Whenever you |
204 | create a git <<def_repository,repository>>, a branch named | |
205 | "master" is created, and becomes the active branch. In most | |
206 | cases, this contains the local development, though that is | |
207 | purely by convention and is not required. | |
da139813 | 208 | |
f562e6f3 | 209 | [[def_merge]]merge:: |
343cad92 BF |
210 | As a verb: To bring the contents of another |
211 | <<def_branch,branch>> (possibly from an external | |
212 | <<def_repository,repository>>) into the current branch. In the | |
213 | case where the merged-in branch is from a different repository, | |
214 | this is done by first <<def_fetch,fetching>> the remote branch | |
215 | and then merging the result into the current branch. This | |
216 | combination of fetch and merge operations is called a | |
217 | <<def_pull,pull>>. Merging is performed by an automatic process | |
218 | that identifies changes made since the branches diverged, and | |
219 | then applies all those changes together. In cases where changes | |
220 | conflict, manual intervention may be required to complete the | |
221 | merge. | |
222 | + | |
223 | As a noun: unless it is a <<def_fast_forward,fast forward>>, a | |
224 | successful merge results in the creation of a new <<def_commit,commit>> | |
225 | representing the result of the merge, and having as | |
226 | <<def_parent,parents>> the tips of the merged <<def_branch,branches>>. | |
227 | This commit is referred to as a "merge commit", or sometimes just a | |
228 | "merge". | |
f562e6f3 BF |
229 | |
230 | [[def_object]]object:: | |
231 | The unit of storage in git. It is uniquely identified by the | |
232 | <<def_SHA1,SHA1>> of its contents. Consequently, an | |
343cad92 | 233 | object can not be changed. |
f562e6f3 BF |
234 | |
235 | [[def_object_database]]object database:: | |
236 | Stores a set of "objects", and an individual <<def_object,object>> is | |
237 | identified by its <<def_object_name,object name>>. The objects usually | |
238 | live in `$GIT_DIR/objects/`. | |
239 | ||
240 | [[def_object_identifier]]object identifier:: | |
241 | Synonym for <<def_object_name,object name>>. | |
242 | ||
243 | [[def_object_name]]object name:: | |
244 | The unique identifier of an <<def_object,object>>. The <<def_hash,hash>> | |
343cad92 | 245 | of the object's contents using the Secure Hash Algorithm |
f562e6f3 | 246 | 1 and usually represented by the 40 character hexadecimal encoding of |
343cad92 | 247 | the <<def_hash,hash>> of the object (possibly followed by |
f562e6f3 BF |
248 | a white space). |
249 | ||
250 | [[def_object_type]]object type:: | |
251 | One of the identifiers | |
cbd91922 | 252 | "<<def_commit,commit>>","<<def_tree,tree>>","<<def_tag,tag>>" or "<<def_blob_object,blob>>" |
f562e6f3 BF |
253 | describing the type of an <<def_object,object>>. |
254 | ||
255 | [[def_octopus]]octopus:: | |
a58f3c01 | 256 | To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an |
f562e6f3 BF |
257 | intelligent predator. |
258 | ||
259 | [[def_origin]]origin:: | |
260 | The default upstream <<def_repository,repository>>. Most projects have | |
261 | at least one upstream project which they track. By default | |
343cad92 | 262 | 'origin' is used for that purpose. New upstream updates |
a58f3c01 | 263 | will be fetched into remote <<def_tracking_branch,tracking branches>> named |
cbd91922 | 264 | origin/name-of-upstream-branch, which you can see using |
a58f3c01 | 265 | "`git branch -r`". |
f1671ecb | 266 | |
f562e6f3 BF |
267 | [[def_pack]]pack:: |
268 | A set of objects which have been compressed into one file (to save space | |
269 | or to transmit them efficiently). | |
da139813 | 270 | |
f562e6f3 | 271 | [[def_pack_index]]pack index:: |
aa9b1573 | 272 | The list of identifiers, and other information, of the objects in a |
f562e6f3 | 273 | <<def_pack,pack>>, to assist in efficiently accessing the contents of a |
343cad92 | 274 | pack. |
f562e6f3 BF |
275 | |
276 | [[def_parent]]parent:: | |
277 | A <<def_commit_object,commit object>> contains a (possibly empty) list | |
278 | of the logical predecessor(s) in the line of development, i.e. its | |
279 | parents. | |
280 | ||
281 | [[def_pickaxe]]pickaxe:: | |
282 | The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore | |
283 | routines that help select changes that add or delete a given text | |
284 | string. With the --pickaxe-all option, it can be used to view the full | |
285 | <<def_changeset,changeset>> that introduced or removed, say, a | |
286 | particular line of text. See gitlink:git-diff[1]. | |
287 | ||
288 | [[def_plumbing]]plumbing:: | |
289 | Cute name for <<def_core_git,core git>>. | |
290 | ||
291 | [[def_porcelain]]porcelain:: | |
292 | Cute name for programs and program suites depending on | |
293 | <<def_core_git,core git>>, presenting a high level access to | |
343cad92 | 294 | core git. Porcelains expose more of a <<def_SCM,SCM>> |
f562e6f3 BF |
295 | interface than the <<def_plumbing,plumbing>>. |
296 | ||
297 | [[def_pull]]pull:: | |
298 | Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and | |
343cad92 | 299 | <<def_merge,merge>> it. See also gitlink:git-pull[1]. |
f562e6f3 BF |
300 | |
301 | [[def_push]]push:: | |
343cad92 | 302 | Pushing a <<def_branch,branch>> means to get the branch's |
f562e6f3 | 303 | <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, |
343cad92 BF |
304 | find out if it is an ancestor to the branch's local |
305 | head ref is a direct, and in that case, putting all | |
f562e6f3 | 306 | objects, which are <<def_reachable,reachable>> from the local |
343cad92 BF |
307 | head ref, and which are missing from the remote |
308 | repository, into the remote | |
f562e6f3 | 309 | <<def_object_database,object database>>, and updating the remote |
343cad92 BF |
310 | head ref. If the remote <<def_head,head>> is not an |
311 | ancestor to the local head, the push fails. | |
f562e6f3 BF |
312 | |
313 | [[def_reachable]]reachable:: | |
314 | All of the ancestors of a given <<def_commit,commit>> are said to be | |
343cad92 BF |
315 | "reachable" from that commit. More |
316 | generally, one <<def_object,object>> is reachable from | |
f562e6f3 | 317 | another if we can reach the one from the other by a <<def_chain,chain>> |
cbd91922 BF |
318 | that follows <<def_tag,tags>> to whatever they tag, |
319 | <<def_commit_object,commits>> to their parents or trees, and | |
320 | <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> | |
321 | that they contain. | |
f562e6f3 BF |
322 | |
323 | [[def_rebase]]rebase:: | |
cbd91922 BF |
324 | To reapply a series of changes from a <<def_branch,branch>> to a |
325 | different base, and reset the <<def_head,head>> of that branch | |
326 | to the result. | |
f562e6f3 BF |
327 | |
328 | [[def_ref]]ref:: | |
329 | A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that | |
330 | denotes a particular <<def_object,object>>. These may be stored in | |
331 | `$GIT_DIR/refs/`. | |
332 | ||
333 | [[def_refspec]]refspec:: | |
a58f3c01 | 334 | A "refspec" is used by <<def_fetch,fetch>> and |
343cad92 BF |
335 | <<def_push,push>> to describe the mapping between remote |
336 | <<def_ref,ref>> and local ref. They are combined with a colon in | |
337 | the format <src>:<dst>, preceded by an optional plus sign, +. | |
338 | For example: `git fetch $URL | |
339 | refs/heads/master:refs/heads/origin` means "grab the master | |
340 | <<def_branch,branch>> <<def_head,head>> from the $URL and store | |
341 | it as my origin branch head". And `git push | |
342 | $URL refs/heads/master:refs/heads/to-upstream` means "publish my | |
343 | master branch head as to-upstream branch at $URL". See also | |
344 | gitlink:git-push[1] | |
f562e6f3 BF |
345 | |
346 | [[def_repository]]repository:: | |
a58f3c01 | 347 | A collection of <<def_ref,refs>> together with an |
343cad92 BF |
348 | <<def_object_database,object database>> containing all objects |
349 | which are <<def_reachable,reachable>> from the refs, possibly | |
a58f3c01 JN |
350 | accompanied by meta data from one or more <<def_porcelain,porcelains>>. A |
351 | repository can share an object database with other repositories | |
352 | via <<def_alternate_object_database,alternates mechanism>>. | |
f562e6f3 BF |
353 | |
354 | [[def_resolve]]resolve:: | |
355 | The action of fixing up manually what a failed automatic | |
356 | <<def_merge,merge>> left behind. | |
357 | ||
358 | [[def_revision]]revision:: | |
359 | A particular state of files and directories which was stored in the | |
360 | <<def_object_database,object database>>. It is referenced by a | |
361 | <<def_commit_object,commit object>>. | |
362 | ||
363 | [[def_rewind]]rewind:: | |
364 | To throw away part of the development, i.e. to assign the | |
365 | <<def_head,head>> to an earlier <<def_revision,revision>>. | |
366 | ||
367 | [[def_SCM]]SCM:: | |
da139813 JS |
368 | Source code management (tool). |
369 | ||
f562e6f3 BF |
370 | [[def_SHA1]]SHA1:: |
371 | Synonym for <<def_object_name,object name>>. | |
372 | ||
373 | [[def_shallow_repository]]shallow repository:: | |
a58f3c01 JN |
374 | A shallow <<def_repository,repository>> has an incomplete |
375 | history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other | |
f562e6f3 BF |
376 | words, git is told to pretend that these commits do not have the |
377 | parents, even though they are recorded in the <<def_commit_object,commit | |
378 | object>>). This is sometimes useful when you are interested only in the | |
379 | recent history of a project even though the real history recorded in the | |
343cad92 | 380 | upstream is much larger. A shallow repository |
cbd91922 BF |
381 | is created by giving the `--depth` option to gitlink:git-clone[1], and |
382 | its history can be later deepened with gitlink:git-fetch[1]. | |
428ddc5d | 383 | |
f562e6f3 | 384 | [[def_symref]]symref:: |
343cad92 BF |
385 | Symbolic reference: instead of containing the <<def_SHA1,SHA1>> |
386 | id itself, it is of the format 'ref: refs/some/thing' and when | |
387 | referenced, it recursively dereferences to this reference. | |
388 | '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic | |
389 | references are manipulated with the gitlink:git-symbolic-ref[1] | |
390 | command. | |
f562e6f3 BF |
391 | |
392 | [[def_tag]]tag:: | |
a58f3c01 | 393 | A <<def_ref,ref>> pointing to a <<def_tag_object,tag>> or |
f562e6f3 | 394 | <<def_commit_object,commit object>>. In contrast to a <<def_head,head>>, |
cbd91922 BF |
395 | a tag is not changed by a <<def_commit,commit>>. Tags (not |
396 | <<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. A | |
397 | git tag has nothing to do with a Lisp tag (which would be | |
398 | called an <<def_object_type,object type>> in git's context). A | |
399 | tag is most typically used to mark a particular point in the | |
343cad92 | 400 | commit ancestry <<def_chain,chain>>. |
f562e6f3 BF |
401 | |
402 | [[def_tag_object]]tag object:: | |
403 | An <<def_object,object>> containing a <<def_ref,ref>> pointing to | |
343cad92 | 404 | another object, which can contain a message just like a |
f562e6f3 | 405 | <<def_commit_object,commit object>>. It can also contain a (PGP) |
a58f3c01 | 406 | signature, in which case it is called a "signed tag object". |
f562e6f3 BF |
407 | |
408 | [[def_topic_branch]]topic branch:: | |
409 | A regular git <<def_branch,branch>> that is used by a developer to | |
410 | identify a conceptual line of development. Since branches are very easy | |
411 | and inexpensive, it is often desirable to have several small branches | |
412 | that each contain very well defined concepts or small incremental yet | |
413 | related changes. | |
414 | ||
415 | [[def_tracking_branch]]tracking branch:: | |
416 | A regular git <<def_branch,branch>> that is used to follow changes from | |
343cad92 BF |
417 | another <<def_repository,repository>>. A tracking |
418 | branch should not contain direct modifications or have local commits | |
419 | made to it. A tracking branch can usually be | |
f562e6f3 BF |
420 | identified as the right-hand-side <<def_ref,ref>> in a Pull: |
421 | <<def_refspec,refspec>>. | |
422 | ||
423 | [[def_tree]]tree:: | |
424 | Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree | |
a58f3c01 | 425 | object>> together with the dependent <<def_blob_object,blob>> and tree objects |
343cad92 | 426 | (i.e. a stored representation of a working tree). |
f562e6f3 BF |
427 | |
428 | [[def_tree_object]]tree object:: | |
429 | An <<def_object,object>> containing a list of file names and modes along | |
cbd91922 | 430 | with refs to the associated blob and/or tree objects. A |
f562e6f3 BF |
431 | <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. |
432 | ||
433 | [[def_tree-ish]]tree-ish:: | |
434 | A <<def_ref,ref>> pointing to either a <<def_commit_object,commit | |
435 | object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag | |
343cad92 | 436 | object>> pointing to a tag or commit or tree object. |
f562e6f3 BF |
437 | |
438 | [[def_unmerged_index]]unmerged index:: | |
cbd91922 BF |
439 | An <<def_index,index>> which contains unmerged |
440 | <<def_index_entry,index entries>>. | |
f562e6f3 BF |
441 | |
442 | [[def_unreachable_object]]unreachable object:: | |
443 | An <<def_object,object>> which is not <<def_reachable,reachable>> from a | |
444 | <<def_branch,branch>>, <<def_tag,tag>>, or any other reference. | |
445 | ||
446 | [[def_working_tree]]working tree:: | |
343cad92 BF |
447 | The tree of actual checked out files. The working tree is |
448 | normally equal to the <<def_HEAD,HEAD>> plus any local changes | |
449 | that you have made but not yet committed. |