<commit_before>GIT Glossary
============

[[def_alternate_object_database]]alternate object database::
	Via the alternates mechanism, a <<def_repository,repository>>
	can inherit part of its <<def_object_database,object database>>
	from another object database, which is called "alternate".

[[def_bare_repository]]bare repository::
	A bare repository is normally an appropriately
	named <<def_directory,directory>> with a `.git` suffix that does not
	have a locally checked-out copy of any of the files under
	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
	`repository.git` directory instead,
	and no other files are present and checked out. Usually publishers of
	public repositories make bare repositories available.

[[def_blob_object]]blob object::
	Untyped <<def_object,object>>, e.g. the contents of a file.

[[def_branch]]branch::
	A "branch" is an active line of development.  The most recent
	<<def_commit,commit>> on a branch is referred to as the tip of
	that branch.  The tip of the branch is referenced by a branch
	<<def_head,head>>, which moves forward as additional development
	is done on the branch.  A single git
	<<def_repository,repository>> can track an arbitrary number of
	branches, but your <<def_working_tree,working tree>> is
	associated with just one of them (the "current" or "checked out"
	branch), and <<def_HEAD,HEAD>> points to that branch.

[[def_cache]]cache::
	Obsolete for: <<def_index,index>>.

[[def_chain]]chain::
	A list of objects, where each <<def_object,object>> in the list contains
	a reference to its successor (for example, the successor of a
	<<def_commit,commit>> could be one of its <<def_parent,parents>>).

[[def_changeset]]changeset::
	BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not
	store changes, but states, it really does not make sense to use the term
	"changesets" with git.

[[def_checkout]]checkout::
	The action of updating the <<def_working_tree,working tree>> to a
	<<def_revision,revision>> which was stored in the
	<<def_object_database,object database>>.

[[def_cherry-picking]]cherry-picking::
	In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
	changes out of a series of changes (typically commits) and record them
	as a new series of changes on top of different codebase. In GIT, this is
	performed by "git cherry-pick" command to extract the change introduced
	by an existing <<def_commit,commit>> and to record it based on the tip
	of the current <<def_branch,branch>> as a new commit.

[[def_clean]]clean::
	A <<def_working_tree,working tree>> is clean, if it
	corresponds to the <<def_revision,revision>> referenced by the current
	<<def_head,head>>. Also see "<<def_dirty,dirty>>".

[[def_commit]]commit::
	As a noun: A single point in the
	git history; the entire history of a project is represented as a
	set of interrelated commits.  The word "commit" is often
	used by git in the same places other revision control systems
	use the words "revision" or "version".  Also used as a short
	hand for <<def_commit_object,commit object>>.
+
As a verb: The action of storing a new snapshot of the project's
state in the git history, by creating a new commit representing the current
state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>>
to point at the new commit.

[[def_commit_object]]commit object::
	An <<def_object,object>> which contains the information about a
	particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer,
	author, date and the <<def_tree_object,tree object>> which corresponds
	to the top <<def_directory,directory>> of the stored
	revision.

[[def_core_git]]core git::
	Fundamental data structures and utilities of git. Exposes only limited
	source code management tools.

[[def_DAG]]DAG::
	Directed acyclic graph. The <<def_commit,commit>> objects form a
	directed acyclic graph, because they have parents (directed), and the
	graph of commit objects is acyclic (there is no
	<<def_chain,chain>> which begins and ends with the same
	<<def_object,object>>).

[[def_dangling_object]]dangling object::
	An <<def_unreachable_object,unreachable object>> which is not
	<<def_reachable,reachable>> even from other unreachable objects; a
	dangling object has no references to it from any
	reference or <<def_object,object>> in the <<def_repository,repository>>.

[[def_detached_HEAD]]detached HEAD::
	Normally the <<def_HEAD,HEAD>> stores the name of a
	<<def_branch,branch>>.  However, git also allows you to <<def_checkout,check out>>
	an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any
	particular branch.  In this case HEAD is said to be "detached".

[[def_dircache]]dircache::
	You are *waaaaay* behind. See <<def_index,index>>.

[[def_directory]]directory::
	The list you get with "ls" :-)

[[def_dirty]]dirty::
	A <<def_working_tree,working tree>> is said to be "dirty" if
	it contains modifications which have not been <<def_commit,committed>> to the current
	<<def_branch,branch>>.

[[def_ent]]ent::
	Favorite synonym to "<<def_tree-ish,tree-ish>>" by some total geeks. See
	`http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
	explanation. Avoid this term, not to confuse people.

[[def_fast_forward]]fast forward::
	A fast-forward is a special type of <<def_merge,merge>> where you have a
	<<def_revision,revision>> and you are "merging" another
	<<def_branch,branch>>'s changes that happen to be a descendant of what
	you have. In such these cases, you do not make a new <<def_merge,merge>>
	<<def_commit,commit>> but instead just update to his
	revision. This will happen frequently on a
	<<def_tracking_branch,tracking branch>> of a remote
	<<def_repository,repository>>.

[[def_fetch]]fetch::
	Fetching a <<def_branch,branch>> means to get the
	branch's <<def_head_ref,head ref>> from a remote
	<<def_repository,repository>>, to find out which objects are
	missing from the local <<def_object_database,object database>>,
	and to get them, too.  See also gitlink:git-fetch[1].

[[def_file_system]]file system::
	Linus Torvalds originally designed git to be a user space file system,
	i.e. the infrastructure to hold files and directories. That ensured the
	efficiency and speed of git.

[[def_git_archive]]git archive::
	Synonym for <<def_repository,repository>> (for arch people).

[[def_grafts]]grafts::
	Grafts enables two otherwise different lines of development to be joined
	together by recording fake ancestry information for commits. This way
	you can make git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has
	is different from what was recorded when the commit was<commit_msg>Documentation: Add definition of "evil merge" to GIT Glossary<commit_after>GIT Glossary
============

[[def_alternate_object_database]]alternate object database::
	Via the alternates mechanism, a <<def_repository,repository>>
	can inherit part of its <<def_object_database,object database>>
	from another object database, which is called "alternate".

[[def_bare_repository]]bare repository::
	A bare repository is normally an appropriately
	named <<def_directory,directory>> with a `.git` suffix that does not
	have a locally checked-out copy of any of the files under
	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
	`repository.git` directory instead,
	and no other files are present and checked out. Usually publishers of
	public repositories make bare repositories available.

[[def_blob_object]]blob object::
	Untyped <<def_object,object>>, e.g. the contents of a file.

[[def_branch]]branch::
	A "branch" is an active line of development.  The most recent
	<<def_commit,commit>> on a branch is referred to as the tip of
	that branch.  The tip of the branch is referenced by a branch
	<<def_head,head>>, which moves forward as additional development
	is done on the branch.  A single git
	<<def_repository,repository>> can track an arbitrary number of
	branches, but your <<def_working_tree,working tree>> is
	associated with just one of them (the "current" or "checked out"
	branch), and <<def_HEAD,HEAD>> points to that branch.

[[def_cache]]cache::
	Obsolete for: <<def_index,index>>.

[[def_chain]]chain::
	A list of objects, where each <<def_object,object>> in the list contains
	a reference to its successor (for example, the successor of a
	<<def_commit,commit>> could be one of its <<def_parent,parents>>).

[[def_changeset]]changeset::
	BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not
	store changes, but states, it really does not make sense to use the term
	"changesets" with git.

[[def_checkout]]checkout::
	The action of updating the <<def_working_tree,working tree>> to a
	<<def_revision,revision>> which was stored in the
	<<def_object_database,object database>>.

[[def_cherry-picking]]cherry-picking::
	In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
	changes out of a series of changes (typically commits) and record them
	as a new series of changes on top of different codebase. In GIT, this is
	performed by "git cherry-pick" command to extract the change introduced
	by an existing <<def_commit,commit>> and to record it based on the tip
	of the current <<def_branch,branch>> as a new commit.

[[def_clean]]clean::
	A <<def_working_tree,working tree>> is clean, if it
	corresponds to the <<def_revision,revision>> referenced by the current
	<<def_head,head>>. Also see "<<def_dirty,dirty>>".

[[def_commit]]commit::
	As a noun: A single point in the
	git history; the entire history of a project is represented as a
	set of interrelated commits.  The word "commit" is often
	used by git in the same places other revision control systems
	use the words "revision" or "version".  Also used as a short
	hand for <<def_commit_object,commit object>>.
+
As a verb: The action of storing a new snapshot of the project's
state in the git history, by creating a new commit representing the current
state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>>
to point at the new commit.

[[def_commit_object]]commit object::
	An <<def_object,object>> which contains the information about a
	particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer,
	author, date and the <<def_tree_object,tree object>> which corresponds
	to the top <<def_directory,directory>> of the stored
	revision.

[[def_core_git]]core git::
	Fundamental data structures and utilities of git. Exposes only limited
	source code management tools.

[[def_DAG]]DAG::
	Directed acyclic graph. The <<def_commit,commit>> objects form a
	directed acyclic graph, because they have parents (directed), and the
	graph of commit objects is acyclic (there is no
	<<def_chain,chain>> which begins and ends with the same
	<<def_object,object>>).

[[def_dangling_object]]dangling object::
	An <<def_unreachable_object,unreachable object>> which is not
	<<def_reachable,reachable>> even from other unreachable objects; a
	dangling object has no references to it from any
	reference or <<def_object,object>> in the <<def_repository,repository>>.

[[def_detached_HEAD]]detached HEAD::
	Normally the <<def_HEAD,HEAD>> stores the name of a
	<<def_branch,branch>>.  However, git also allows you to <<def_checkout,check out>>
	an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any
	particular branch.  In this case HEAD is said to be "detached".

[[def_dircache]]dircache::
	You are *waaaaay* behind. See <<def_index,index>>.

[[def_directory]]directory::
	The list you get with "ls" :-)

[[def_dirty]]dirty::
	A <<def_working_tree,working tree>> is said to be "dirty" if
	it contains modifications which have not been <<def_commit,committed>> to the current
	<<def_branch,branch>>.

[[def_ent]]ent::
	Favorite synonym to "<<def_tree-ish,tree-ish>>" by some total geeks. See
	`http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
	explanation. Avoid this term, not to confuse people.

[[def_evil_merge]]evil merge::
	An evil merge is a <<def_merge,merge>> that introduces changes that
	do not appear in any <<def_parent,parent>>.

[[def_fast_forward]]fast forward::
	A fast-forward is a special type of <<def_merge,merge>> where you have a
	<<def_revision,revision>> and you are "merging" another
	<<def_branch,branch>>'s changes that happen to be a descendant of what
	you have. In such these cases, you do not make a new <<def_merge,merge>>
	<<def_commit,commit>> but instead just update to his
	revision. This will happen frequently on a
	<<def_tracking_branch,tracking branch>> of a remote
	<<def_repository,repository>>.

[[def_fetch]]fetch::
	Fetching a <<def_branch,branch>> means to get the
	branch's <<def_head_ref,head ref>> from a remote
	<<def_repository,repository>>, to find out which objects are
	missing from the local <<def_object_database,object database>>,
	and to get them, too.  See also gitlink:git-fetch[1].

[[def_file_system]]file system::
	<NAME> originally designed git to be a user space file system,
	i.e. the infrastructure to hold files and directories. That ensured the
	efficiency and speed of git.

[[def_git_archive]]git archive::
	Synonym for <<def_repository,repository>> (for arch people).

[[def_grafts]]grafts::
	Grafts enables two otherwise different lines of development to be joined
	together by recording fake ancestry information for commits. This way
	you can make git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has
	is different from what was recorded when the commit was
{'fraction_non_alphanumeric': 0.09688733011836914, 'fraction_numerical': 0.00014613473622680112, 'mean_word_length': 5.41377694470478, 'pattern_counts': {'":': 0, '<': 256, '<?xml version=': 0, '>': 256, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '783179', 'n_tokens_mistral': 4101, 'n_tokens_neox': 4002, 'n_words': 1722}