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@xxxxxxxxxxxxx/T/#u
[2]
https://public-inbox.org/git/20180403165143.80661-1-dstolee@xxxxxxxxxxxxx/T/#u
