@@ -49,23 +49,23 @@ Equivalently, the generation number of a commit A is one more than the
length of a longest path from A to a root commit. The recursive definition
is easier to use for computation and observing the following property:
- If A and B are commits with generation numbers N and M, respectively,
- and N <= M, then A cannot reach B. That is, we know without searching
- that B is not an ancestor of A because it is further from a root commit
- than A.
+If A and B are commits with generation numbers N and M, respectively,
+and N <= M, then A cannot reach B. That is, we know without searching
+that B is not an ancestor of A because it is further from a root commit
+than A.
- Conversely, when checking if A is an ancestor of B, then we only need
- to walk commits until all commits on the walk boundary have generation
- number at most N. If we walk commits using a priority queue seeded by
- generation numbers, then we always expand the boundary commit with highest
- generation number and can easily detect the stopping condition.
+Conversely, when checking if A is an ancestor of B, then we only need
+to walk commits until all commits on the walk boundary have generation
+number at most N. If we walk commits using a priority queue seeded by
+generation numbers, then we always expand the boundary commit with highest
+generation number and can easily detect the stopping condition.
This property can be used to significantly reduce the time it takes to
walk commits and determine topological relationships. Without generation
numbers, the general heuristic is the following:
- If A and B are commits with commit time X and Y, respectively, and
- X < Y, then A _probably_ cannot reach B.
+If A and B are commits with commit time X and Y, respectively, and
+X < Y, then A _probably_ cannot reach B.
This heuristic is currently used whenever the computation is allowed to
violate topological relationships due to clock skew (such as "git log"
@@ -121,11 +121,8 @@ Future Work
- After computing and storing generation numbers, we must make graph
walks aware of generation numbers to gain the performance benefits they
enable. This will mostly be accomplished by swapping a commit-date-ordered
- priority queue with one ordered by generation number. The following
- operations are important candidates:
-
- - 'log --topo-order'
- - 'tag --merged'
+ priority queue with one ordered by generation number. Commands that could
+ improve include 'git log --topo-order' and 'git tag --merged'.
- A server could provide a commit graph file as part of the network protocol
to avoid extra calculations by clients. This feature is only of benefit if
@@ -148,13 +145,13 @@ Related Links
More discussion about generation numbers and not storing them inside
commit objects. A valuable quote:
- "I think we should be moving more in the direction of keeping
- repo-local caches for optimizations. Reachability bitmaps have been
- a big performance win. I think we should be doing the same with our
- properties of commits. Not just generation numbers, but making it
- cheap to access the graph structure without zlib-inflating whole
- commit objects (i.e., packv4 or something like the "metapacks" I
- proposed a few years ago)."
+"I think we should be moving more in the direction of keeping
+ repo-local caches for optimizations. Reachability bitmaps have been
+ a big performance win. I think we should be doing the same with our
+ properties of commits. Not just generation numbers, but making it
+ cheap to access the graph structure without zlib-inflating whole
+ commit objects (i.e., packv4 or something like the "metapacks" I
+ proposed a few years ago)."
[4] https://public-inbox.org/git/20180108154822.54829-1-git@jeffhostetler.com/T/#u
A patch to remove the ahead-behind calculation from 'status'.