On 4/9/2018 6:21 AM, Junio C Hamano wrote:

* ds/commit-graph (2018-04-02) 16 commits
  - commit-graph: implement "--additive" option
  - commit-graph: build graph from starting commits
  - commit-graph: read only from specific pack-indexes
  - commit: integrate commit graph with commit parsing
  - commit-graph: close under reachability
  - commit-graph: add core.commitGraph setting
  - commit-graph: implement git commit-graph read
  - commit-graph: implement git-commit-graph write
  - commit-graph: implement write_commit_graph()
  - commit-graph: create git-commit-graph builtin
  - graph: add commit graph design document
  - commit-graph: add format document
  - csum-file: refactor finalize_hashfile() method
  - csum-file: rename hashclose() to finalize_hashfile()
  - Merge branch 'jk/cached-commit-buffer' into HEAD
  - Merge branch 'jt/binsearch-with-fanout' into HEAD
  (this branch is used by ds/lazy-load-trees.)

  Precompute and store information necessary for ancestry traversal
  in a separate file to optimize graph walking.

  Ready???
  It seems that this topic is getting there.

I think this patch is ready to go, barring the edit of "--additive" to 
"--append" in the final commit message and squashing following diff into 
"commit-graph: implement git commit-graph read":

@@ -31,7 +31,7 @@ static struct opts_commit_graph {

  static int graph_read(int argc, const char **argv)
  {
-       struct commit_graph *graph = 0;
+       struct commit_graph *graph = NULL;
         char *graph_name;

         static struct option builtin_commit_graph_read_options[] = {

If you prefer that I re-roll with those changes, I can send a v8.

I'm currently working on new series based on this feature:

* [1] Lazy-load trees when reading commit-graph (ds/lazy-load-trees)

* [2] Compute and consume generation numbers

* Move commit-graph.c globals to the_repository

* Implement 'fsck' functionality for the commit-graph file

* Integrate 'commit-graph write' into 'gc --auto'

I would also like to open the feature to other contributors, especially 
for others who can contribute performance improvements using generation 
numbers. We had a very valuable discussion on the list [2], and I look 
forward to more collaborations like that.

Thanks,
-Stolee

[1] 
https://public-inbox.org/git/20180403120057.173849-1-dstolee@microsoft.com/T/#u

[2] 
https://public-inbox.org/git/20180403165143.80661-1-dstolee@microsoft.com/T/#u