mirror of
https://github.com/git/git
synced 2024-08-25 02:35:46 +00:00
Merge branch 'po/glossary-around-traversal'
The glossary entries for "commit-graph file" and "reachability bitmap" have been added. * po/glossary-around-traversal: glossary: add reachability bitmap description glossary: add "commit graph" description doc: use 'object database' not ODB or abbreviation doc: use "commit-graph" hyphenation consistently
This commit is contained in:
commit
4b6302c72f
|
@ -618,7 +618,7 @@ but risks losing recent work in the event of an unclean system shutdown.
|
||||||
* `loose-object` hardens objects added to the repo in loose-object form.
|
* `loose-object` hardens objects added to the repo in loose-object form.
|
||||||
* `pack` hardens objects added to the repo in packfile form.
|
* `pack` hardens objects added to the repo in packfile form.
|
||||||
* `pack-metadata` hardens packfile bitmaps and indexes.
|
* `pack-metadata` hardens packfile bitmaps and indexes.
|
||||||
* `commit-graph` hardens the commit graph file.
|
* `commit-graph` hardens the commit-graph file.
|
||||||
* `index` hardens the index when it is modified.
|
* `index` hardens the index when it is modified.
|
||||||
* `objects` is an aggregate option that is equivalent to
|
* `objects` is an aggregate option that is equivalent to
|
||||||
`loose-object,pack`.
|
`loose-object,pack`.
|
||||||
|
|
|
@ -34,7 +34,7 @@ OPTIONS
|
||||||
|
|
||||||
--alt-odb::
|
--alt-odb::
|
||||||
Don't require objects present in packs from alternate object
|
Don't require objects present in packs from alternate object
|
||||||
directories to be present in local packs.
|
database (odb) directories to be present in local packs.
|
||||||
|
|
||||||
--verbose::
|
--verbose::
|
||||||
Outputs some statistics to stderr. Has a small performance penalty.
|
Outputs some statistics to stderr. Has a small performance penalty.
|
||||||
|
|
|
@ -3,7 +3,7 @@ gitformat-commit-graph(5)
|
||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
gitformat-commit-graph - Git commit graph format
|
gitformat-commit-graph - Git commit-graph format
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
|
@ -14,7 +14,7 @@ $GIT_DIR/objects/info/commit-graphs/*
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
The Git commit graph stores a list of commit OIDs and some associated
|
The Git commit-graph stores a list of commit OIDs and some associated
|
||||||
metadata, including:
|
metadata, including:
|
||||||
|
|
||||||
- The generation number of the commit.
|
- The generation number of the commit.
|
||||||
|
@ -34,7 +34,7 @@ corresponding to the array position within the list of commit OIDs. Due
|
||||||
to some special constants we use to track parents, we can store at most
|
to some special constants we use to track parents, we can store at most
|
||||||
(1 << 30) + (1 << 29) + (1 << 28) - 1 (around 1.8 billion) commits.
|
(1 << 30) + (1 << 29) + (1 << 28) - 1 (around 1.8 billion) commits.
|
||||||
|
|
||||||
== Commit graph files have the following format:
|
== Commit-graph files have the following format:
|
||||||
|
|
||||||
In order to allow extensions that add extra data to the graph, we organize
|
In order to allow extensions that add extra data to the graph, we organize
|
||||||
the body into "chunks" and provide a binary lookup table at the beginning
|
the body into "chunks" and provide a binary lookup table at the beginning
|
||||||
|
|
|
@ -20,7 +20,7 @@
|
||||||
[[def_branch]]branch::
|
[[def_branch]]branch::
|
||||||
A "branch" is a line of development. The most recent
|
A "branch" is a line of development. The most recent
|
||||||
<<def_commit,commit>> on a branch is referred to as the tip of
|
<<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
|
that branch. The tip of the branch is <<def_ref,referenced>> by a branch
|
||||||
<<def_head,head>>, which moves forward as additional development
|
<<def_head,head>>, which moves forward as additional development
|
||||||
is done on the branch. A single Git
|
is done on the branch. A single Git
|
||||||
<<def_repository,repository>> can track an arbitrary number of
|
<<def_repository,repository>> can track an arbitrary number of
|
||||||
|
@ -75,6 +75,21 @@ state in the Git history, by creating a new commit representing the current
|
||||||
state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>>
|
state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>>
|
||||||
to point at the new commit.
|
to point at the new commit.
|
||||||
|
|
||||||
|
[[def_commit_graph_general]]commit graph concept, representations and usage::
|
||||||
|
A synonym for the <<def_DAG,DAG>> structure formed by the commits
|
||||||
|
in the object database, <<def_ref,referenced>> by branch tips,
|
||||||
|
using their <<def_chain,chain>> of linked commits.
|
||||||
|
This structure is the definitive commit graph. The
|
||||||
|
graph can be represented in other ways, e.g. the
|
||||||
|
<<def_commit_graph_file,"commit-graph" file>>.
|
||||||
|
|
||||||
|
[[def_commit_graph_file]]commit-graph file::
|
||||||
|
The "commit-graph" (normally hyphenated) file is a supplemental
|
||||||
|
representation of the <<def_commit_graph_general,commit graph>>
|
||||||
|
which accelerates commit graph walks. The "commit-graph" file is
|
||||||
|
stored either in the .git/objects/info directory or in the info
|
||||||
|
directory of an alternate object database.
|
||||||
|
|
||||||
[[def_commit_object]]commit object::
|
[[def_commit_object]]commit object::
|
||||||
An <<def_object,object>> which contains the information about a
|
An <<def_object,object>> which contains the information about a
|
||||||
particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer,
|
particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer,
|
||||||
|
@ -262,7 +277,7 @@ This commit is referred to as a "merge commit", or sometimes just a
|
||||||
identified by its <<def_object_name,object name>>. The objects usually
|
identified by its <<def_object_name,object name>>. The objects usually
|
||||||
live in `$GIT_DIR/objects/`.
|
live in `$GIT_DIR/objects/`.
|
||||||
|
|
||||||
[[def_object_identifier]]object identifier::
|
[[def_object_identifier]]object identifier (oid)::
|
||||||
Synonym for <<def_object_name,object name>>.
|
Synonym for <<def_object_name,object name>>.
|
||||||
|
|
||||||
[[def_object_name]]object name::
|
[[def_object_name]]object name::
|
||||||
|
@ -493,6 +508,14 @@ exclude;;
|
||||||
<<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>>
|
<<def_tree_object,trees>> to the trees or <<def_blob_object,blobs>>
|
||||||
that they contain.
|
that they contain.
|
||||||
|
|
||||||
|
[[def_reachability_bitmap]]reachability bitmaps::
|
||||||
|
Reachability bitmaps store information about the
|
||||||
|
<<def_reachable,reachability>> of a selected set of commits in
|
||||||
|
a packfile, or a multi-pack index (MIDX), to speed up object search.
|
||||||
|
The bitmaps are stored in a ".bitmap" file. A repository may have at
|
||||||
|
most one bitmap file in use. The bitmap file may belong to either one
|
||||||
|
pack, or the repository's multi-pack index (if it exists).
|
||||||
|
|
||||||
[[def_rebase]]rebase::
|
[[def_rebase]]rebase::
|
||||||
To reapply a series of changes from a <<def_branch,branch>> to a
|
To reapply a series of changes from a <<def_branch,branch>> to a
|
||||||
different base, and reset the <<def_head,head>> of that branch
|
different base, and reset the <<def_head,head>> of that branch
|
||||||
|
|
|
@ -1,4 +1,4 @@
|
||||||
Git Commit Graph Design Notes
|
Git Commit-Graph Design Notes
|
||||||
=============================
|
=============================
|
||||||
|
|
||||||
Git walks the commit graph for many reasons, including:
|
Git walks the commit graph for many reasons, including:
|
||||||
|
@ -17,7 +17,7 @@ There are two main costs here:
|
||||||
|
|
||||||
The commit-graph file is a supplemental data structure that accelerates
|
The commit-graph file is a supplemental data structure that accelerates
|
||||||
commit graph walks. If a user downgrades or disables the 'core.commitGraph'
|
commit graph walks. If a user downgrades or disables the 'core.commitGraph'
|
||||||
config setting, then the existing ODB is sufficient. The file is stored
|
config setting, then the existing object database is sufficient. The file is stored
|
||||||
as "commit-graph" either in the .git/objects/info directory or in the info
|
as "commit-graph" either in the .git/objects/info directory or in the info
|
||||||
directory of an alternate.
|
directory of an alternate.
|
||||||
|
|
||||||
|
@ -95,7 +95,7 @@ with default order), but is not used when the topological order is
|
||||||
required (such as merge base calculations, "git log --graph").
|
required (such as merge base calculations, "git log --graph").
|
||||||
|
|
||||||
In practice, we expect some commits to be created recently and not stored
|
In practice, we expect some commits to be created recently and not stored
|
||||||
in the commit graph. We can treat these commits as having "infinite"
|
in the commit-graph. We can treat these commits as having "infinite"
|
||||||
generation number and walk until reaching commits with known generation
|
generation number and walk until reaching commits with known generation
|
||||||
number.
|
number.
|
||||||
|
|
||||||
|
@ -149,7 +149,7 @@ Design Details
|
||||||
helpful for these clones, anyway. The commit-graph will not be read or
|
helpful for these clones, anyway. The commit-graph will not be read or
|
||||||
written when shallow commits are present.
|
written when shallow commits are present.
|
||||||
|
|
||||||
Commit Graphs Chains
|
Commit-Graphs Chains
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
Typically, repos grow with near-constant velocity (commits per day). Over time,
|
Typically, repos grow with near-constant velocity (commits per day). Over time,
|
||||||
|
|
|
@ -56,7 +56,7 @@ Rejected Multi-Threaded Solution
|
||||||
|
|
||||||
The most "straightforward" implementation would be to spread the set of
|
The most "straightforward" implementation would be to spread the set of
|
||||||
to-be-updated cache entries across multiple threads. But due to the
|
to-be-updated cache entries across multiple threads. But due to the
|
||||||
thread-unsafe functions in the ODB code, we would have to use locks to
|
thread-unsafe functions in the object database code, we would have to use locks to
|
||||||
coordinate the parallel operation. An early prototype of this solution
|
coordinate the parallel operation. An early prototype of this solution
|
||||||
showed that the multi-threaded checkout would bring performance
|
showed that the multi-threaded checkout would bring performance
|
||||||
improvements over the sequential code, but there was still too much lock
|
improvements over the sequential code, but there was still too much lock
|
||||||
|
|
Loading…
Reference in a new issue