]>
Commit | Line | Data |
---|---|---|
f562e6f3 | 1 | [[def_alternate_object_database]]alternate object database:: |
343cad92 BF |
2 | Via the alternates mechanism, a <<def_repository,repository>> |
3 | can inherit part of its <<def_object_database,object database>> | |
3c735e07 | 4 | from another object database, which is called an "alternate". |
f562e6f3 BF |
5 | |
6 | [[def_bare_repository]]bare repository:: | |
343cad92 | 7 | A bare repository is normally an appropriately |
f562e6f3 BF |
8 | named <<def_directory,directory>> with a `.git` suffix that does not |
9 | have a locally checked-out copy of any of the files under | |
2de9b711 | 10 | revision control. That is, all of the Git |
f562e6f3 BF |
11 | administrative and control files that would normally be present in the |
12 | hidden `.git` sub-directory are directly present in the | |
cbd91922 | 13 | `repository.git` directory instead, |
f562e6f3 BF |
14 | and no other files are present and checked out. Usually publishers of |
15 | public repositories make bare repositories available. | |
16 | ||
17 | [[def_blob_object]]blob object:: | |
18 | Untyped <<def_object,object>>, e.g. the contents of a file. | |
19 | ||
20 | [[def_branch]]branch:: | |
eef1ceab | 21 | A "branch" is a line of development. The most recent |
343cad92 | 22 | <<def_commit,commit>> on a branch is referred to as the tip of |
4973726c | 23 | that branch. The tip of the branch is <<def_ref,referenced>> by a branch |
343cad92 | 24 | <<def_head,head>>, which moves forward as additional development |
2de9b711 | 25 | is done on the branch. A single Git |
343cad92 BF |
26 | <<def_repository,repository>> can track an arbitrary number of |
27 | branches, but your <<def_working_tree,working tree>> is | |
28 | associated with just one of them (the "current" or "checked out" | |
29 | branch), and <<def_HEAD,HEAD>> points to that branch. | |
f562e6f3 BF |
30 | |
31 | [[def_cache]]cache:: | |
32 | Obsolete for: <<def_index,index>>. | |
33 | ||
34 | [[def_chain]]chain:: | |
35 | A list of objects, where each <<def_object,object>> in the list contains | |
36 | a reference to its successor (for example, the successor of a | |
a58f3c01 | 37 | <<def_commit,commit>> could be one of its <<def_parent,parents>>). |
f562e6f3 BF |
38 | |
39 | [[def_changeset]]changeset:: | |
2de9b711 | 40 | BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not |
f562e6f3 | 41 | store changes, but states, it really does not make sense to use the term |
2de9b711 | 42 | "changesets" with Git. |
f562e6f3 BF |
43 | |
44 | [[def_checkout]]checkout:: | |
76ce9462 JP |
45 | The action of updating all or part of the |
46 | <<def_working_tree,working tree>> with a <<def_tree_object,tree object>> | |
47 | or <<def_blob_object,blob>> from the | |
48 | <<def_object_database,object database>>, and updating the | |
49 | <<def_index,index>> and <<def_HEAD,HEAD>> if the whole working tree has | |
50 | been pointed at a new <<def_branch,branch>>. | |
f562e6f3 BF |
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 | |
48a8c26c | 55 | as a new series of changes on top of a different codebase. In Git, this is |
06ada152 | 56 | performed by the "git cherry-pick" command to extract the change introduced |
f562e6f3 | 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 | 66 | As a noun: A single point in the |
2de9b711 | 67 | Git history; the entire history of a project is represented as a |
343cad92 | 68 | set of interrelated commits. The word "commit" is often |
2de9b711 | 69 | used by Git in the same places other revision control systems |
343cad92 BF |
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 | |
2de9b711 | 74 | state in the Git history, by creating a new commit representing the current |
343cad92 BF |
75 | state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>> |
76 | to point at the new commit. | |
f562e6f3 | 77 | |
4973726c PO |
78 | [[def_commit_graph_general]]commit graph concept, representations and usage:: |
79 | A synonym for the <<def_DAG,DAG>> structure formed by the commits | |
80 | in the object database, <<def_ref,referenced>> by branch tips, | |
81 | using their <<def_chain,chain>> of linked commits. | |
82 | This structure is the definitive commit graph. The | |
83 | graph can be represented in other ways, e.g. the | |
84 | <<def_commit_graph_file,"commit-graph" file>>. | |
85 | ||
86 | [[def_commit_graph_file]]commit-graph file:: | |
87 | The "commit-graph" (normally hyphenated) file is a supplemental | |
88 | representation of the <<def_commit_graph_general,commit graph>> | |
89 | which accelerates commit graph walks. The "commit-graph" file is | |
90 | stored either in the .git/objects/info directory or in the info | |
91 | directory of an alternate object database. | |
92 | ||
f562e6f3 BF |
93 | [[def_commit_object]]commit object:: |
94 | An <<def_object,object>> which contains the information about a | |
a58f3c01 | 95 | particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer, |
f562e6f3 BF |
96 | author, date and the <<def_tree_object,tree object>> which corresponds |
97 | to the top <<def_directory,directory>> of the stored | |
a58f3c01 | 98 | revision. |
f562e6f3 | 99 | |
406fde17 | 100 | [[def_commit-ish]]commit-ish (also committish):: |
893dce2f VD |
101 | A <<def_commit_object,commit object>> or an <<def_object,object>> that |
102 | can be recursively <<def_dereference,dereferenced>> to a commit object. | |
406fde17 RH |
103 | The following are all commit-ishes: |
104 | a commit object, | |
105 | a <<def_tag_object,tag object>> that points to a commit | |
106 | object, | |
107 | a tag object that points to a tag object that points to a | |
108 | commit object, | |
109 | etc. | |
110 | ||
2de9b711 TA |
111 | [[def_core_git]]core Git:: |
112 | Fundamental data structures and utilities of Git. Exposes only limited | |
f562e6f3 BF |
113 | source code management tools. |
114 | ||
115 | [[def_DAG]]DAG:: | |
850d3a7c | 116 | Directed acyclic graph. The <<def_commit_object,commit objects>> form a |
f562e6f3 | 117 | directed acyclic graph, because they have parents (directed), and the |
850d3a7c LW |
118 | graph of commit objects is acyclic (there is no <<def_chain,chain>> |
119 | which begins and ends with the same <<def_object,object>>). | |
f562e6f3 BF |
120 | |
121 | [[def_dangling_object]]dangling object:: | |
122 | An <<def_unreachable_object,unreachable object>> which is not | |
123 | <<def_reachable,reachable>> even from other unreachable objects; a | |
343cad92 | 124 | dangling object has no references to it from any |
f562e6f3 BF |
125 | reference or <<def_object,object>> in the <<def_repository,repository>>. |
126 | ||
893dce2f VD |
127 | [[def_dereference]]dereference:: |
128 | Referring to a <<def_symref,symbolic ref>>: the action of accessing the | |
129 | <<def_ref,reference>> pointed at by a symbolic ref. Recursive | |
130 | dereferencing involves repeating the aforementioned process on the | |
131 | resulting ref until a non-symbolic reference is found. | |
132 | + | |
133 | Referring to a <<def_tag_object,tag object>>: the action of accessing the | |
134 | <<def_object,object>> a tag points at. Tags are recursively dereferenced by | |
135 | repeating the operation on the result object until the result has either a | |
136 | specified <<def_object_type,object type>> (where applicable) or any non-"tag" | |
137 | object type. A synonym for "recursive dereference" in the context of tags is | |
138 | "<<def_peel,peel>>". | |
139 | + | |
140 | Referring to a <<def_commit_object,commit object>>: the action of accessing | |
141 | the commit's tree object. Commits cannot be dereferenced recursively. | |
142 | + | |
143 | Unless otherwise specified, "dereferencing" as it used in the context of Git | |
144 | commands or protocols is implicitly recursive. | |
145 | ||
343cad92 BF |
146 | [[def_detached_HEAD]]detached HEAD:: |
147 | Normally the <<def_HEAD,HEAD>> stores the name of a | |
1d77d249 JH |
148 | <<def_branch,branch>>, and commands that operate on the |
149 | history HEAD represents operate on the history leading to the | |
150 | tip of the branch the HEAD points at. However, Git also | |
151 | allows you to <<def_checkout,check out>> an arbitrary | |
152 | <<def_commit,commit>> that isn't necessarily the tip of any | |
153 | particular branch. The HEAD in such a state is called | |
154 | "detached". | |
155 | + | |
156 | Note that commands that operate on the history of the current branch | |
157 | (e.g. `git commit` to build a new history on top of it) still work | |
158 | while the HEAD is detached. They update the HEAD to point at the tip | |
159 | of the updated history without affecting any branch. Commands that | |
160 | update or inquire information _about_ the current branch (e.g. `git | |
d6ac1d21 | 161 | branch --set-upstream-to` that sets what remote-tracking branch the |
1d77d249 JH |
162 | current branch integrates with) obviously do not work, as there is no |
163 | (real) current branch to ask about in this state. | |
343cad92 | 164 | |
f562e6f3 | 165 | [[def_directory]]directory:: |
aa9b1573 | 166 | The list you get with "ls" :-) |
da139813 | 167 | |
f562e6f3 | 168 | [[def_dirty]]dirty:: |
343cad92 | 169 | A <<def_working_tree,working tree>> is said to be "dirty" if |
a58f3c01 | 170 | it contains modifications which have not been <<def_commit,committed>> to the current |
f562e6f3 BF |
171 | <<def_branch,branch>>. |
172 | ||
c1bab288 JN |
173 | [[def_evil_merge]]evil merge:: |
174 | An evil merge is a <<def_merge,merge>> that introduces changes that | |
175 | do not appear in any <<def_parent,parent>>. | |
176 | ||
a75d7b54 | 177 | [[def_fast_forward]]fast-forward:: |
f562e6f3 BF |
178 | A fast-forward is a special type of <<def_merge,merge>> where you have a |
179 | <<def_revision,revision>> and you are "merging" another | |
180 | <<def_branch,branch>>'s changes that happen to be a descendant of what | |
2e39a246 | 181 | you have. In such a case, you do not make a new <<def_merge,merge>> |
e22f2dae R |
182 | <<def_commit,commit>> but instead just update your branch to point at the same |
183 | revision as the branch you are merging. This will happen frequently on a | |
8b3f3f84 | 184 | <<def_remote_tracking_branch,remote-tracking branch>> of a remote |
f562e6f3 BF |
185 | <<def_repository,repository>>. |
186 | ||
187 | [[def_fetch]]fetch:: | |
188 | Fetching a <<def_branch,branch>> means to get the | |
343cad92 BF |
189 | branch's <<def_head_ref,head ref>> from a remote |
190 | <<def_repository,repository>>, to find out which objects are | |
191 | missing from the local <<def_object_database,object database>>, | |
5162e697 | 192 | and to get them, too. See also linkgit:git-fetch[1]. |
f562e6f3 BF |
193 | |
194 | [[def_file_system]]file system:: | |
2de9b711 | 195 | Linus Torvalds originally designed Git to be a user space file system, |
f562e6f3 | 196 | i.e. the infrastructure to hold files and directories. That ensured the |
2de9b711 | 197 | efficiency and speed of Git. |
f562e6f3 | 198 | |
2de9b711 | 199 | [[def_git_archive]]Git archive:: |
f562e6f3 BF |
200 | Synonym for <<def_repository,repository>> (for arch people). |
201 | ||
19b4d3d4 TA |
202 | [[def_gitfile]]gitfile:: |
203 | A plain file `.git` at the root of a working tree that | |
204 | points at the directory that is the real repository. | |
e4299d26 MK |
205 | For proper use see linkgit:git-worktree[1] or linkgit:git-submodule[1]. |
206 | For syntax see linkgit:gitrepository-layout[5]. | |
19b4d3d4 | 207 | |
f562e6f3 | 208 | [[def_grafts]]grafts:: |
ce14cc0b | 209 | Grafts enable two otherwise different lines of development to be joined |
f562e6f3 | 210 | together by recording fake ancestry information for commits. This way |
2de9b711 | 211 | you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has |
343cad92 | 212 | is different from what was recorded when the commit was |
cbd91922 | 213 | created. Configured via the `.git/info/grafts` file. |
e650d064 JK |
214 | + |
215 | Note that the grafts mechanism is outdated and can lead to problems | |
216 | transferring objects between repositories; see linkgit:git-replace[1] | |
217 | for a more flexible and robust system to do the same thing. | |
f562e6f3 BF |
218 | |
219 | [[def_hash]]hash:: | |
3ab50120 | 220 | In Git's context, synonym for <<def_object_name,object name>>. |
f562e6f3 BF |
221 | |
222 | [[def_head]]head:: | |
a58f3c01 | 223 | A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a |
deaef1e9 JH |
224 | <<def_branch,branch>>. Heads are stored in a file in |
225 | `$GIT_DIR/refs/heads/` directory, except when using packed refs. (See | |
5162e697 | 226 | linkgit:git-pack-refs[1].) |
343cad92 BF |
227 | |
228 | [[def_HEAD]]HEAD:: | |
a58f3c01 | 229 | The current <<def_branch,branch>>. In more detail: Your <<def_working_tree, |
343cad92 BF |
230 | working tree>> is normally derived from the state of the tree |
231 | referred to by HEAD. HEAD is a reference to one of the | |
232 | <<def_head,heads>> in your repository, except when using a | |
67393c5d JH |
233 | <<def_detached_HEAD,detached HEAD>>, in which case it directly |
234 | references an arbitrary commit. | |
f562e6f3 BF |
235 | |
236 | [[def_head_ref]]head ref:: | |
343cad92 | 237 | A synonym for <<def_head,head>>. |
f562e6f3 BF |
238 | |
239 | [[def_hook]]hook:: | |
2de9b711 | 240 | During the normal execution of several Git commands, call-outs are made |
f562e6f3 BF |
241 | to optional scripts that allow a developer to add functionality or |
242 | checking. Typically, the hooks allow for a command to be pre-verified | |
243 | and potentially aborted, and allow for a post-notification after the | |
343cad92 | 244 | operation is done. The hook scripts are found in the |
a58f3c01 | 245 | `$GIT_DIR/hooks/` directory, and are enabled by simply |
d1983677 | 246 | removing the `.sample` suffix from the filename. In earlier versions |
2de9b711 | 247 | of Git you had to make them executable. |
f562e6f3 BF |
248 | |
249 | [[def_index]]index:: | |
250 | A collection of files with stat information, whose contents are stored | |
a58f3c01 JN |
251 | as objects. The index is a stored version of your |
252 | <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even | |
253 | a third version of a working tree, which are used | |
254 | when <<def_merge,merging>>. | |
f562e6f3 BF |
255 | |
256 | [[def_index_entry]]index entry:: | |
257 | The information regarding a particular file, stored in the | |
343cad92 BF |
258 | <<def_index,index>>. An index entry can be unmerged, if a |
259 | <<def_merge,merge>> was started, but not yet finished (i.e. if | |
260 | the index contains multiple versions of that file). | |
f562e6f3 BF |
261 | |
262 | [[def_master]]master:: | |
343cad92 | 263 | The default development <<def_branch,branch>>. Whenever you |
2de9b711 | 264 | create a Git <<def_repository,repository>>, a branch named |
343cad92 BF |
265 | "master" is created, and becomes the active branch. In most |
266 | cases, this contains the local development, though that is | |
267 | purely by convention and is not required. | |
da139813 | 268 | |
f562e6f3 | 269 | [[def_merge]]merge:: |
343cad92 BF |
270 | As a verb: To bring the contents of another |
271 | <<def_branch,branch>> (possibly from an external | |
272 | <<def_repository,repository>>) into the current branch. In the | |
273 | case where the merged-in branch is from a different repository, | |
274 | this is done by first <<def_fetch,fetching>> the remote branch | |
275 | and then merging the result into the current branch. This | |
276 | combination of fetch and merge operations is called a | |
277 | <<def_pull,pull>>. Merging is performed by an automatic process | |
278 | that identifies changes made since the branches diverged, and | |
279 | then applies all those changes together. In cases where changes | |
280 | conflict, manual intervention may be required to complete the | |
281 | merge. | |
282 | + | |
a75d7b54 | 283 | As a noun: unless it is a <<def_fast_forward,fast-forward>>, a |
343cad92 BF |
284 | successful merge results in the creation of a new <<def_commit,commit>> |
285 | representing the result of the merge, and having as | |
286 | <<def_parent,parents>> the tips of the merged <<def_branch,branches>>. | |
287 | This commit is referred to as a "merge commit", or sometimes just a | |
288 | "merge". | |
f562e6f3 BF |
289 | |
290 | [[def_object]]object:: | |
2de9b711 | 291 | The unit of storage in Git. It is uniquely identified by the |
3ab50120 | 292 | <<def_SHA1,SHA-1>> of its contents. Consequently, an |
6d169227 | 293 | object cannot be changed. |
f562e6f3 BF |
294 | |
295 | [[def_object_database]]object database:: | |
296 | Stores a set of "objects", and an individual <<def_object,object>> is | |
297 | identified by its <<def_object_name,object name>>. The objects usually | |
298 | live in `$GIT_DIR/objects/`. | |
299 | ||
fa8e8d5b | 300 | [[def_object_identifier]]object identifier (oid):: |
f562e6f3 BF |
301 | Synonym for <<def_object_name,object name>>. |
302 | ||
303 | [[def_object_name]]object name:: | |
3ab50120 TA |
304 | The unique identifier of an <<def_object,object>>. The |
305 | object name is usually represented by a 40 character | |
306 | hexadecimal string. Also colloquially called <<def_SHA1,SHA-1>>. | |
f562e6f3 BF |
307 | |
308 | [[def_object_type]]object type:: | |
850d3a7c LW |
309 | One of the identifiers "<<def_commit_object,commit>>", |
310 | "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or | |
311 | "<<def_blob_object,blob>>" describing the type of an | |
312 | <<def_object,object>>. | |
f562e6f3 BF |
313 | |
314 | [[def_octopus]]octopus:: | |
79de4558 | 315 | To <<def_merge,merge>> more than two <<def_branch,branches>>. |
f562e6f3 BF |
316 | |
317 | [[def_origin]]origin:: | |
318 | The default upstream <<def_repository,repository>>. Most projects have | |
319 | at least one upstream project which they track. By default | |
343cad92 | 320 | 'origin' is used for that purpose. New upstream updates |
d6ac1d21 | 321 | will be fetched into <<def_remote_tracking_branch,remote-tracking branches>> named |
cbd91922 | 322 | origin/name-of-upstream-branch, which you can see using |
dcb11263 | 323 | `git branch -r`. |
f1671ecb | 324 | |
7aba8140 TG |
325 | [[def_overlay]]overlay:: |
326 | Only update and add files to the working directory, but don't | |
327 | delete them, similar to how 'cp -R' would update the contents | |
328 | in the destination directory. This is the default mode in a | |
329 | <<def_checkout,checkout>> when checking out files from the | |
330 | <<def_index,index>> or a <<def_tree-ish,tree-ish>>. In | |
331 | contrast, no-overlay mode also deletes tracked files not | |
332 | present in the source, similar to 'rsync --delete'. | |
333 | ||
f562e6f3 BF |
334 | [[def_pack]]pack:: |
335 | A set of objects which have been compressed into one file (to save space | |
336 | or to transmit them efficiently). | |
da139813 | 337 | |
f562e6f3 | 338 | [[def_pack_index]]pack index:: |
aa9b1573 | 339 | The list of identifiers, and other information, of the objects in a |
f562e6f3 | 340 | <<def_pack,pack>>, to assist in efficiently accessing the contents of a |
343cad92 | 341 | pack. |
f562e6f3 | 342 | |
3bd2bcfa | 343 | [[def_pathspec]]pathspec:: |
57148ebb | 344 | Pattern used to limit paths in Git commands. |
3bd2bcfa JN |
345 | + |
346 | Pathspecs are used on the command line of "git ls-files", "git | |
8a42c985 JH |
347 | ls-tree", "git add", "git grep", "git diff", "git checkout", |
348 | and many other commands to | |
3bd2bcfa | 349 | limit the scope of operations to some subset of the tree or |
2df5387e | 350 | working tree. See the documentation of each command for whether |
3bd2bcfa JN |
351 | paths are relative to the current directory or toplevel. The |
352 | pathspec syntax is as follows: | |
57148ebb TA |
353 | + |
354 | -- | |
3bd2bcfa JN |
355 | |
356 | * any path matches itself | |
357 | * the pathspec up to the last slash represents a | |
358 | directory prefix. The scope of that pathspec is | |
359 | limited to that subtree. | |
360 | * the rest of the pathspec is a pattern for the remainder | |
361 | of the pathname. Paths relative to the directory | |
362 | prefix will be matched against that pattern using fnmatch(3); | |
363 | in particular, '*' and '?' _can_ match directory separators. | |
57148ebb TA |
364 | |
365 | -- | |
3bd2bcfa JN |
366 | + |
367 | For example, Documentation/*.jpg will match all .jpg files | |
368 | in the Documentation subtree, | |
369 | including Documentation/chapter_1/figure_1.jpg. | |
8a42c985 JH |
370 | + |
371 | A pathspec that begins with a colon `:` has special meaning. In the | |
372 | short form, the leading colon `:` is followed by zero or more "magic | |
373 | signature" letters (which optionally is terminated by another colon `:`), | |
8b7cb51a NTND |
374 | and the remainder is the pattern to match against the path. |
375 | The "magic signature" consists of ASCII symbols that are neither | |
f745acb0 | 376 | alphanumeric, glob, regex special characters nor colon. |
8b7cb51a NTND |
377 | The optional colon that terminates the "magic signature" can be |
378 | omitted if the pattern begins with a character that does not belong to | |
379 | "magic signature" symbol set and is not a colon. | |
8a42c985 | 380 | + |
928f0ab4 | 381 | In the long form, the leading colon `:` is followed by an open |
8a42c985 JH |
382 | parenthesis `(`, a comma-separated list of zero or more "magic words", |
383 | and a close parentheses `)`, and the remainder is the pattern to match | |
384 | against the path. | |
385 | + | |
8b7cb51a NTND |
386 | A pathspec with only a colon means "there is no pathspec". This form |
387 | should not be combined with other pathspec. | |
5c6933d2 NTND |
388 | + |
389 | -- | |
8b7cb51a NTND |
390 | top;; |
391 | The magic word `top` (magic signature: `/`) makes the pattern | |
392 | match from the root of the working tree, even when you are | |
393 | running the command from inside a subdirectory. | |
5c6933d2 NTND |
394 | |
395 | literal;; | |
396 | Wildcards in the pattern such as `*` or `?` are treated | |
397 | as literal characters. | |
bd30c2e4 | 398 | |
93d93537 NTND |
399 | icase;; |
400 | Case insensitive match. | |
401 | ||
bd30c2e4 NTND |
402 | glob;; |
403 | Git treats the pattern as a shell glob suitable for | |
404 | consumption by fnmatch(3) with the FNM_PATHNAME flag: | |
405 | wildcards in the pattern will not match a / in the pathname. | |
406 | For example, "Documentation/{asterisk}.html" matches | |
407 | "Documentation/git.html" but not "Documentation/ppc/ppc.html" | |
408 | or "tools/perf/Documentation/perf.html". | |
409 | + | |
410 | Two consecutive asterisks ("`**`") in patterns matched against | |
411 | full pathname may have special meaning: | |
412 | ||
413 | - A leading "`**`" followed by a slash means match in all | |
414 | directories. For example, "`**/foo`" matches file or directory | |
746be68d | 415 | "`foo`" anywhere, the same as pattern "`foo`". "`**/foo/bar`" |
bd30c2e4 NTND |
416 | matches file or directory "`bar`" anywhere that is directly |
417 | under directory "`foo`". | |
418 | ||
746be68d NTND |
419 | - A trailing "`/**`" matches everything inside. For example, |
420 | "`abc/**`" matches all files inside directory "abc", relative | |
bd30c2e4 NTND |
421 | to the location of the `.gitignore` file, with infinite depth. |
422 | ||
423 | - A slash followed by two consecutive asterisks then a slash | |
424 | matches zero or more directories. For example, "`a/**/b`" | |
425 | matches "`a/b`", "`a/x/b`", "`a/x/y/b`" and so on. | |
426 | ||
427 | - Other consecutive asterisks are considered invalid. | |
428 | + | |
429 | Glob magic is incompatible with literal magic. | |
ef79b1f8 | 430 | |
b0db7046 BW |
431 | attr;; |
432 | After `attr:` comes a space separated list of "attribute | |
433 | requirements", all of which must be met in order for the | |
434 | path to be considered a match; this is in addition to the | |
435 | usual non-magic pathspec pattern matching. | |
436 | See linkgit:gitattributes[5]. | |
437 | + | |
438 | Each of the attribute requirements for the path takes one of | |
439 | these forms: | |
440 | ||
441 | - "`ATTR`" requires that the attribute `ATTR` be set. | |
442 | ||
443 | - "`-ATTR`" requires that the attribute `ATTR` be unset. | |
444 | ||
445 | - "`ATTR=VALUE`" requires that the attribute `ATTR` be | |
446 | set to the string `VALUE`. | |
447 | ||
448 | - "`!ATTR`" requires that the attribute `ATTR` be | |
449 | unspecified. | |
450 | + | |
5a0b97b3 NTND |
451 | Note that when matching against a tree object, attributes are still |
452 | obtained from working tree, not from the given tree object. | |
b0db7046 | 453 | |
ef79b1f8 NTND |
454 | exclude;; |
455 | After a path matches any non-exclude pathspec, it will be run | |
93dbefb3 | 456 | through all exclude pathspecs (magic signature: `!` or its |
859b7f1d LT |
457 | synonym `^`). If it matches, the path is ignored. When there |
458 | is no non-exclude pathspec, the exclusion is applied to the | |
459 | result set as if invoked without any pathspec. | |
5c6933d2 | 460 | -- |
8a42c985 | 461 | |
f562e6f3 BF |
462 | [[def_parent]]parent:: |
463 | A <<def_commit_object,commit object>> contains a (possibly empty) list | |
464 | of the logical predecessor(s) in the line of development, i.e. its | |
465 | parents. | |
466 | ||
893dce2f VD |
467 | [[def_peel]]peel:: |
468 | The action of recursively <<def_dereference,dereferencing>> a | |
469 | <<def_tag_object,tag object>>. | |
470 | ||
f562e6f3 BF |
471 | [[def_pickaxe]]pickaxe:: |
472 | The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore | |
473 | routines that help select changes that add or delete a given text | |
b6cbca38 | 474 | string. With the `--pickaxe-all` option, it can be used to view the full |
f562e6f3 | 475 | <<def_changeset,changeset>> that introduced or removed, say, a |
5162e697 | 476 | particular line of text. See linkgit:git-diff[1]. |
f562e6f3 BF |
477 | |
478 | [[def_plumbing]]plumbing:: | |
2de9b711 | 479 | Cute name for <<def_core_git,core Git>>. |
f562e6f3 BF |
480 | |
481 | [[def_porcelain]]porcelain:: | |
482 | Cute name for programs and program suites depending on | |
2de9b711 TA |
483 | <<def_core_git,core Git>>, presenting a high level access to |
484 | core Git. Porcelains expose more of a <<def_SCM,SCM>> | |
f562e6f3 BF |
485 | interface than the <<def_plumbing,plumbing>>. |
486 | ||
2036cb98 | 487 | [[def_per_worktree_ref]]per-worktree ref:: |
2df5387e | 488 | Refs that are per-<<def_worktree,worktree>>, rather than |
ce414b33 DT |
489 | global. This is presently only <<def_HEAD,HEAD>> and any refs |
490 | that start with `refs/bisect/`, but might later include other | |
491 | unusual refs. | |
2036cb98 DT |
492 | |
493 | [[def_pseudoref]]pseudoref:: | |
494 | Pseudorefs are a class of files under `$GIT_DIR` which behave | |
495 | like refs for the purposes of rev-parse, but which are treated | |
496 | specially by git. Pseudorefs both have names that are all-caps, | |
497 | and always start with a line consisting of a | |
498 | <<def_SHA1,SHA-1>> followed by whitespace. So, HEAD is not a | |
499 | pseudoref, because it is sometimes a symbolic ref. They might | |
500 | optionally contain some additional data. `MERGE_HEAD` and | |
501 | `CHERRY_PICK_HEAD` are examples. Unlike | |
502 | <<def_per_worktree_ref,per-worktree refs>>, these files cannot | |
503 | be symbolic refs, and never have reflogs. They also cannot be | |
504 | updated through the normal ref update machinery. Instead, | |
505 | they are updated by directly writing to the files. However, | |
506 | they can be read as if they were refs, so `git rev-parse | |
507 | MERGE_HEAD` will work. | |
508 | ||
f562e6f3 BF |
509 | [[def_pull]]pull:: |
510 | Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and | |
5162e697 | 511 | <<def_merge,merge>> it. See also linkgit:git-pull[1]. |
f562e6f3 BF |
512 | |
513 | [[def_push]]push:: | |
343cad92 | 514 | Pushing a <<def_branch,branch>> means to get the branch's |
f562e6f3 | 515 | <<def_head_ref,head ref>> from a remote <<def_repository,repository>>, |
a279b74c | 516 | find out if it is an ancestor to the branch's local |
2c619db8 | 517 | head ref, and in that case, putting all |
f562e6f3 | 518 | objects, which are <<def_reachable,reachable>> from the local |
343cad92 BF |
519 | head ref, and which are missing from the remote |
520 | repository, into the remote | |
f562e6f3 | 521 | <<def_object_database,object database>>, and updating the remote |
343cad92 BF |
522 | head ref. If the remote <<def_head,head>> is not an |
523 | ancestor to the local head, the push fails. | |
f562e6f3 BF |
524 | |
525 | [[def_reachable]]reachable:: | |
526 | All of the ancestors of a given <<def_commit,commit>> are said to be | |
343cad92 BF |
527 | "reachable" from that commit. More |
528 | generally, one <<def_object,object>> is reachable from | |
f562e6f3 | 529 | another if we can reach the one from the other by a <<def_chain,chain>> |
cbd91922 BF |
530 | that follows <<def_tag,tags>> to whatever they tag, |
531 | <<def_commit_object,commits>> to their parents or trees, and | |
532 | <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>> | |
533 | that they contain. | |
f562e6f3 | 534 | |
8fea12ab PO |
535 | [[def_reachability_bitmap]]reachability bitmaps:: |
536 | Reachability bitmaps store information about the | |
537 | <<def_reachable,reachability>> of a selected set of commits in | |
538 | a packfile, or a multi-pack index (MIDX), to speed up object search. | |
539 | The bitmaps are stored in a ".bitmap" file. A repository may have at | |
540 | most one bitmap file in use. The bitmap file may belong to either one | |
541 | pack, or the repository's multi-pack index (if it exists). | |
542 | ||
f562e6f3 | 543 | [[def_rebase]]rebase:: |
cbd91922 BF |
544 | To reapply a series of changes from a <<def_branch,branch>> to a |
545 | different base, and reset the <<def_head,head>> of that branch | |
546 | to the result. | |
f562e6f3 BF |
547 | |
548 | [[def_ref]]ref:: | |
4b6acde5 RH |
549 | A name that begins with `refs/` (e.g. `refs/heads/master`) |
550 | that points to an <<def_object_name,object name>> or another | |
551 | ref (the latter is called a <<def_symref,symbolic ref>>). | |
552 | For convenience, a ref can sometimes be abbreviated when used | |
553 | as an argument to a Git command; see linkgit:gitrevisions[7] | |
554 | for details. | |
555 | Refs are stored in the <<def_repository,repository>>. | |
556 | + | |
557 | The ref namespace is hierarchical. | |
558 | Different subhierarchies are used for different purposes (e.g. the | |
559 | `refs/heads/` hierarchy is used to represent local branches). | |
560 | + | |
561 | There are a few special-purpose refs that do not begin with `refs/`. | |
562 | The most notable example is `HEAD`. | |
f562e6f3 | 563 | |
f8d69576 JS |
564 | [[def_reflog]]reflog:: |
565 | A reflog shows the local "history" of a ref. In other words, | |
566 | it can tell you what the 3rd last revision in _this_ repository | |
567 | was, and what was the current state in _this_ repository, | |
5162e697 | 568 | yesterday 9:14pm. See linkgit:git-reflog[1] for details. |
f8d69576 | 569 | |
f562e6f3 | 570 | [[def_refspec]]refspec:: |
a58f3c01 | 571 | A "refspec" is used by <<def_fetch,fetch>> and |
343cad92 | 572 | <<def_push,push>> to describe the mapping between remote |
57148ebb | 573 | <<def_ref,ref>> and local ref. |
f562e6f3 | 574 | |
e6a268c5 SB |
575 | [[def_remote]]remote repository:: |
576 | A <<def_repository,repository>> which is used to track the same | |
577 | project but resides somewhere else. To communicate with remotes, | |
578 | see <<def_fetch,fetch>> or <<def_push,push>>. | |
579 | ||
8b3f3f84 | 580 | [[def_remote_tracking_branch]]remote-tracking branch:: |
229177aa JH |
581 | A <<def_ref,ref>> that is used to follow changes from another |
582 | <<def_repository,repository>>. It typically looks like | |
583 | 'refs/remotes/foo/bar' (indicating that it tracks a branch named | |
584 | 'bar' in a remote named 'foo'), and matches the right-hand-side of | |
585 | a configured fetch <<def_refspec,refspec>>. A remote-tracking | |
586 | branch should not contain direct modifications or have local | |
587 | commits made to it. | |
8b3f3f84 | 588 | |
f562e6f3 | 589 | [[def_repository]]repository:: |
a58f3c01 | 590 | A collection of <<def_ref,refs>> together with an |
343cad92 BF |
591 | <<def_object_database,object database>> containing all objects |
592 | which are <<def_reachable,reachable>> from the refs, possibly | |
a58f3c01 JN |
593 | accompanied by meta data from one or more <<def_porcelain,porcelains>>. A |
594 | repository can share an object database with other repositories | |
595 | via <<def_alternate_object_database,alternates mechanism>>. | |
f562e6f3 BF |
596 | |
597 | [[def_resolve]]resolve:: | |
598 | The action of fixing up manually what a failed automatic | |
599 | <<def_merge,merge>> left behind. | |
600 | ||
601 | [[def_revision]]revision:: | |
dfb44106 | 602 | Synonym for <<def_commit,commit>> (the noun). |
f562e6f3 BF |
603 | |
604 | [[def_rewind]]rewind:: | |
605 | To throw away part of the development, i.e. to assign the | |
606 | <<def_head,head>> to an earlier <<def_revision,revision>>. | |
607 | ||
608 | [[def_SCM]]SCM:: | |
da139813 JS |
609 | Source code management (tool). |
610 | ||
3ab50120 TA |
611 | [[def_SHA1]]SHA-1:: |
612 | "Secure Hash Algorithm 1"; a cryptographic hash function. | |
613 | In the context of Git used as a synonym for <<def_object_name,object name>>. | |
f562e6f3 | 614 | |
bac58749 SS |
615 | [[def_shallow_clone]]shallow clone:: |
616 | Mostly a synonym to <<def_shallow_repository,shallow repository>> | |
617 | but the phrase makes it more explicit that it was created by | |
618 | running `git clone --depth=...` command. | |
619 | ||
f562e6f3 | 620 | [[def_shallow_repository]]shallow repository:: |
a58f3c01 JN |
621 | A shallow <<def_repository,repository>> has an incomplete |
622 | history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other | |
2de9b711 | 623 | words, Git is told to pretend that these commits do not have the |
f562e6f3 BF |
624 | parents, even though they are recorded in the <<def_commit_object,commit |
625 | object>>). This is sometimes useful when you are interested only in the | |
626 | recent history of a project even though the real history recorded in the | |
343cad92 | 627 | upstream is much larger. A shallow repository |
5162e697 DM |
628 | is created by giving the `--depth` option to linkgit:git-clone[1], and |
629 | its history can be later deepened with linkgit:git-fetch[1]. | |
428ddc5d | 630 | |
90f64f1c LB |
631 | [[def_stash]]stash entry:: |
632 | An <<def_object,object>> used to temporarily store the contents of a | |
633 | <<def_dirty,dirty>> working directory and the index for future reuse. | |
634 | ||
e6a268c5 SB |
635 | [[def_submodule]]submodule:: |
636 | A <<def_repository,repository>> that holds the history of a | |
637 | separate project inside another repository (the latter of | |
638 | which is called <<def_superproject, superproject>>). | |
639 | ||
640 | [[def_superproject]]superproject:: | |
641 | A <<def_repository,repository>> that references repositories | |
642 | of other projects in its working tree as <<def_submodule,submodules>>. | |
643 | The superproject knows about the names of (but does not hold | |
644 | copies of) commit objects of the contained submodules. | |
645 | ||
f562e6f3 | 646 | [[def_symref]]symref:: |
893dce2f VD |
647 | Symbolic reference: instead of containing the <<def_SHA1,SHA-1>> id |
648 | itself, it is of the format 'ref: refs/some/thing' and when referenced, | |
649 | it recursively <<def_dereference,dereferences>> to this reference. | |
650 | '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic references | |
651 | are manipulated with the linkgit:git-symbolic-ref[1] command. | |
f562e6f3 BF |
652 | |
653 | [[def_tag]]tag:: | |
487b0441 JH |
654 | A <<def_ref,ref>> under `refs/tags/` namespace that points to an |
655 | object of an arbitrary type (typically a tag points to either a | |
656 | <<def_tag_object,tag>> or a <<def_commit_object,commit object>>). | |
657 | In contrast to a <<def_head,head>>, a tag is not updated by | |
2de9b711 | 658 | the `commit` command. A Git tag has nothing to do with a Lisp |
487b0441 | 659 | tag (which would be called an <<def_object_type,object type>> |
2de9b711 | 660 | in Git's context). A tag is most typically used to mark a particular |
487b0441 | 661 | point in the commit ancestry <<def_chain,chain>>. |
f562e6f3 BF |
662 | |
663 | [[def_tag_object]]tag object:: | |
664 | An <<def_object,object>> containing a <<def_ref,ref>> pointing to | |
343cad92 | 665 | another object, which can contain a message just like a |
f562e6f3 | 666 | <<def_commit_object,commit object>>. It can also contain a (PGP) |
a58f3c01 | 667 | signature, in which case it is called a "signed tag object". |
f562e6f3 BF |
668 | |
669 | [[def_topic_branch]]topic branch:: | |
2de9b711 | 670 | A regular Git <<def_branch,branch>> that is used by a developer to |
f562e6f3 BF |
671 | identify a conceptual line of development. Since branches are very easy |
672 | and inexpensive, it is often desirable to have several small branches | |
673 | that each contain very well defined concepts or small incremental yet | |
674 | related changes. | |
675 | ||
f562e6f3 BF |
676 | [[def_tree]]tree:: |
677 | Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree | |
a58f3c01 | 678 | object>> together with the dependent <<def_blob_object,blob>> and tree objects |
343cad92 | 679 | (i.e. a stored representation of a working tree). |
f562e6f3 BF |
680 | |
681 | [[def_tree_object]]tree object:: | |
682 | An <<def_object,object>> containing a list of file names and modes along | |
cbd91922 | 683 | with refs to the associated blob and/or tree objects. A |
f562e6f3 BF |
684 | <<def_tree,tree>> is equivalent to a <<def_directory,directory>>. |
685 | ||
36a2a54d | 686 | [[def_tree-ish]]tree-ish (also treeish):: |
893dce2f VD |
687 | A <<def_tree_object,tree object>> or an <<def_object,object>> that can |
688 | be recursively <<def_dereference,dereferenced>> to a tree object. | |
689 | Dereferencing a <<def_commit_object,commit object>> yields the tree | |
690 | object corresponding to the <<def_revision,revision>>'s top | |
691 | <<def_directory,directory>>. | |
930f302c RH |
692 | The following are all tree-ishes: |
693 | a <<def_commit-ish,commit-ish>>, | |
694 | a tree object, | |
695 | a <<def_tag_object,tag object>> that points to a tree object, | |
696 | a tag object that points to a tag object that points to a tree | |
697 | object, | |
698 | etc. | |
f562e6f3 BF |
699 | |
700 | [[def_unmerged_index]]unmerged index:: | |
cbd91922 BF |
701 | An <<def_index,index>> which contains unmerged |
702 | <<def_index_entry,index entries>>. | |
f562e6f3 BF |
703 | |
704 | [[def_unreachable_object]]unreachable object:: | |
705 | An <<def_object,object>> which is not <<def_reachable,reachable>> from a | |
706 | <<def_branch,branch>>, <<def_tag,tag>>, or any other reference. | |
707 | ||
e892dc71 SB |
708 | [[def_upstream_branch]]upstream branch:: |
709 | The default <<def_branch,branch>> that is merged into the branch in | |
710 | question (or the branch in question is rebased onto). It is configured | |
711 | via branch.<name>.remote and branch.<name>.merge. If the upstream branch | |
712 | of 'A' is 'origin/B' sometimes we say "'A' is tracking 'origin/B'". | |
713 | ||
f562e6f3 | 714 | [[def_working_tree]]working tree:: |
580cbb58 JN |
715 | The tree of actual checked out files. The working tree normally |
716 | contains the contents of the <<def_HEAD,HEAD>> commit's tree, | |
717 | plus any local changes that you have made but not yet committed. | |
2df5387e JH |
718 | |
719 | [[def_worktree]]worktree:: | |
720 | A repository can have zero (i.e. bare repository) or one or | |
721 | more worktrees attached to it. One "worktree" consists of a | |
722 | "working tree" and repository metadata, most of which are | |
723 | shared among other worktrees of a single repository, and | |
724 | some of which are maintained separately per worktree | |
725 | (e.g. the index, HEAD and pseudorefs like MERGE_HEAD, | |
726 | per-worktree refs and per-worktree configuration file). |