index 82e17db0c027a2cd451dfaab6cd4d6d8b15ac951..2465514e461a4a6c4e61f04ced18d6229eae0f51 100644 (file)
<<def_revision,revision>> control. That is, all of the `git`
administrative and control files that would normally be present in the
hidden `.git` sub-directory are directly present in the
<<def_revision,revision>> control. That is, all of the `git`
administrative and control files that would normally be present in the
hidden `.git` sub-directory are directly present in the
- `<<def_repository,repository>>.git` <<def_directory,directory>> instead,
+ `repository.git` directory instead,
and no other files are present and checked out. Usually publishers of
public repositories make bare repositories available.
and no other files are present and checked out. Usually publishers of
public repositories make bare repositories available.
[[def_branch]]branch::
A non-cyclical graph of revisions, i.e. the complete history of a
particular <<def_revision,revision>>, which is called the
[[def_branch]]branch::
A non-cyclical graph of revisions, i.e. the complete history of a
particular <<def_revision,revision>>, which is called the
- <<def_branch,branch>> <<def_head,head>>. The <<def_branch,branch>> heads
+ branch <<def_head,head>>. The heads
are stored in `$GIT_DIR/refs/heads/`.
[[def_cache]]cache::
are stored in `$GIT_DIR/refs/heads/`.
[[def_cache]]cache::
together by recording fake ancestry information for commits. This way
you can make git pretend the set of parents a <<def_commit,commit>> has
is different from what was recorded when the <<def_commit,commit>> was
together by recording fake ancestry information for commits. This way
you can make git pretend the set of parents a <<def_commit,commit>> has
is different from what was recorded when the <<def_commit,commit>> was
- created. Configured via the `.git/info/<<def_grafts,grafts>>` file.
+ created. Configured via the `.git/info/grafts` file.
[[def_hash]]hash::
In git's context, synonym to <<def_object_name,object name>>.
[[def_hash]]hash::
In git's context, synonym to <<def_object_name,object name>>.
[[def_object_type]]object type::
One of the identifiers
[[def_object_type]]object type::
One of the identifiers
- "<<def_commit,commit>>","<<def_tree,tree>>","<<def_tag,tag>>" and "blob"
+ "<<def_commit,commit>>","<<def_tree,tree>>","<<def_tag,tag>>" or "<<def_blob_object,blob>>"
describing the type of an <<def_object,object>>.
[[def_octopus]]octopus::
describing the type of an <<def_object,object>>.
[[def_octopus]]octopus::
at least one upstream project which they track. By default
'<<def_origin,origin>>' is used for that purpose. New upstream updates
will be fetched into remote tracking branches named
at least one upstream project which they track. By default
'<<def_origin,origin>>' is used for that purpose. New upstream updates
will be fetched into remote tracking branches named
- <<def_origin,origin>>/name-of-upstream-branch, which you can see using
+ origin/name-of-upstream-branch, which you can see using
"git <<def_branch,branch>> -r".
[[def_pack]]pack::
"git <<def_branch,branch>> -r".
[[def_pack]]pack::
<<def_reachable,reachable>> from that <<def_commit,commit>>. More
generally, one <<def_object,object>> is <<def_reachable,reachable>> from
another if we can reach the one from the other by a <<def_chain,chain>>
<<def_reachable,reachable>> from that <<def_commit,commit>>. More
generally, one <<def_object,object>> is <<def_reachable,reachable>> from
another if we can reach the one from the other by a <<def_chain,chain>>
- that follows tags to whatever they <<def_tag,tag>>, commits to their
- parents or trees, and trees to the trees or blobs that they contain.
+ that follows <<def_tag,tags>> to whatever they tag,
+ <<def_commit_object,commits>> to their parents or trees, and
+ <<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>>
+ that they contain.
[[def_rebase]]rebase::
[[def_rebase]]rebase::
- To <<def_clean,clean>> a <<def_branch,branch>> by starting from the
- <<def_head,head>> of the main line of development
- ("<<def_master,master>>"), and reapply the (possibly cherry-picked)
- changes from that <<def_branch,branch>>.
+ To reapply a series of changes from a <<def_branch,branch>> to a
+ different base, and reset the <<def_head,head>> of that branch
+ to the result.
[[def_ref]]ref::
A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that
[[def_ref]]ref::
A 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that
<<def_push,push>> to describe the mapping between remote <<def_ref,ref>>
and local <<def_ref,ref>>. They are combined with a colon in the format
<src>:<dst>, preceded by an optional plus sign, +. For example: `git
<<def_push,push>> to describe the mapping between remote <<def_ref,ref>>
and local <<def_ref,ref>>. They are combined with a colon in the format
<src>:<dst>, preceded by an optional plus sign, +. For example: `git
- <<def_fetch,fetch>> $URL
- refs/heads/<<def_master,master>>:refs/heads/<<def_origin,origin>>` means
- "grab the <<def_master,master>> <<def_branch,branch>> <<def_head,head>>
- from the $URL and store it as my <<def_origin,origin>>
+ fetch $URL refs/heads/master:refs/heads/origin` means
+ "grab the master <<def_branch,branch>> <<def_head,head>>
+ from the $URL and store it as my origin
<<def_branch,branch>> <<def_head,head>>". And `git <<def_push,push>>
<<def_branch,branch>> <<def_head,head>>". And `git <<def_push,push>>
- $URL refs/heads/<<def_master,master>>:refs/heads/to-upstream` means
- "publish my <<def_master,master>> <<def_branch,branch>>
+ $URL refs/heads/master:refs/heads/to-upstream` means
+ "publish my master <<def_branch,branch>>
<<def_head,head>> as to-upstream <<def_branch,branch>> at $URL". See
also gitlink:git-push[1]
[[def_repository]]repository::
A collection of refs together with an <<def_object_database,object
<<def_head,head>> as to-upstream <<def_branch,branch>> at $URL". See
also gitlink:git-push[1]
[[def_repository]]repository::
A collection of refs together with an <<def_object_database,object
- database>> containing all objects, which are <<def_reachable,reachable>>
+ database>> containing all objects which are <<def_reachable,reachable>>
from the refs, possibly accompanied by meta data from one or more
porcelains. A <<def_repository,repository>> can share an
<<def_object_database,object database>> with other repositories.
from the refs, possibly accompanied by meta data from one or more
porcelains. A <<def_repository,repository>> can share an
<<def_object_database,object database>> with other repositories.
object>>). This is sometimes useful when you are interested only in the
recent history of a project even though the real history recorded in the
upstream is much larger. A <<def_shallow_repository,shallow repository>>
object>>). This is sometimes useful when you are interested only in the
recent history of a project even though the real history recorded in the
upstream is much larger. A <<def_shallow_repository,shallow repository>>
- is created by giving `--depth` option to gitlink:git-clone[1], and its
- history can be later deepened with gitlink:git-fetch[1].
+ is created by giving the `--depth` option to gitlink:git-clone[1], and
+ its history can be later deepened with gitlink:git-fetch[1].
[[def_symref]]symref::
Symbolic reference: instead of containing the <<def_SHA1,SHA1>> id
[[def_symref]]symref::
Symbolic reference: instead of containing the <<def_SHA1,SHA1>> id
- itself, it is of the format '<<def_ref,ref>>: refs/some/thing' and when
+ itself, it is of the format 'ref: refs/some/thing' and when
referenced, it recursively dereferences to this reference. 'HEAD' is a
prime example of a <<def_symref,symref>>. Symbolic references are
manipulated with the gitlink:git-symbolic-ref[1] command.
referenced, it recursively dereferences to this reference. 'HEAD' is a
prime example of a <<def_symref,symref>>. Symbolic references are
manipulated with the gitlink:git-symbolic-ref[1] command.
[[def_tag]]tag::
A <<def_ref,ref>> pointing to a <<def_tag,tag>> or
<<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
[[def_tag]]tag::
A <<def_ref,ref>> pointing to a <<def_tag,tag>> or
<<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
- a <<def_tag,tag>> is not changed by a <<def_commit,commit>>. Tags (not
- <<def_tag,tag>> objects) are stored in `$GIT_DIR/refs/tags/`. A git
- <<def_tag,tag>> has nothing to do with a Lisp <<def_tag,tag>> (which is
- called <<def_object_type,object type>> in git's context). A
- <<def_tag,tag>> is most typically used to mark a particular point in the
+ a tag is not changed by a <<def_commit,commit>>. Tags (not
+ <<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. A
+ git tag has nothing to do with a Lisp tag (which would be
+ called an <<def_object_type,object type>> in git's context). A
+ tag is most typically used to mark a particular point in the
<<def_commit,commit>> ancestry <<def_chain,chain>>.
[[def_tag_object]]tag object::
<<def_commit,commit>> ancestry <<def_chain,chain>>.
[[def_tag_object]]tag object::
[[def_tree_object]]tree object::
An <<def_object,object>> containing a list of file names and modes along
[[def_tree_object]]tree object::
An <<def_object,object>> containing a list of file names and modes along
- with refs to the associated blob and/or <<def_tree,tree>> objects. A
+ with refs to the associated blob and/or tree objects. A
<<def_tree,tree>> is equivalent to a <<def_directory,directory>>.
[[def_tree-ish]]tree-ish::
<<def_tree,tree>> is equivalent to a <<def_directory,directory>>.
[[def_tree-ish]]tree-ish::
<<def_tree_object,tree object>>.
[[def_unmerged_index]]unmerged index::
<<def_tree_object,tree object>>.
[[def_unmerged_index]]unmerged index::
- An <<def_index,index>> which contains <<def_unmerged_index,unmerged
- index>> entries.
+ An <<def_index,index>> which contains unmerged
+ <<def_index_entry,index entries>>.
[[def_unreachable_object]]unreachable object::
An <<def_object,object>> which is not <<def_reachable,reachable>> from a
[[def_unreachable_object]]unreachable object::
An <<def_object,object>> which is not <<def_reachable,reachable>> from a