Re: [PATCH v5 00/13] Serialized Git Commit Graph
From: Stefan Beller <hidden>
Date: 2018-02-27 18:50:40
On Mon, Feb 26, 2018 at 6:32 PM, Derrick Stolee [off-list ref] wrote:
This patch series is another big difference from version 4, but I do think we are converging on a stable design. This series depends on a few things in flight: * jt/binsearch-with-fanout for bsearch_graph() * 'master' includes the sha1file -> hashfile rename in (98a3beab). * [PATCH] commit: drop uses of get_cached_commit_buffer(). [1] I couldn't find a ds/* branch for this one, but it is necessary or else the commit graph test script should fail.
'jk/cached-commit-buffer', 'jk' as the first commit in that series is by Jeff King ? I found this commit by searching for its verbatim title in 'git log --oneline origin/pu' and then using https://github.com/mhagger/git-when-merged to find 51ff16f5f3a (Merge branch 'jk/cached-commit-buffer' into jch, 2018-02-23)
Here are some of the inter-patch changes: * The single commit graph file is stored in the fixed filename .git/objects/info/commit-graph * Because of this change, I struggled with the right way to pair the lockfile API with the hashfile API. Perhaps they were not meant to interact like this. I include a new patch step that adds a flag for hashclose() to keep the file descriptor open so commit_lock_file() can succeed. Please let me know if this is the wrong approach.
This sounds like an interesting thing to review.
* A side-benefit of this change is that the "--set-latest" and "--delete-expired" arguments are no longer useful. * I re-ran the performance tests since I rebased onto master. I had moved my "master" branch on my copy of Linux from another perf test, which changed the data shape a bit. * There was some confusion between v3 and v4 about whether commits in an existing commit-graph file are automatically added to the new file during a write. I think I cleared up all of the documentation that referenced this to the new behavior: we only include commits reachable from the starting commits (depending on --stdin-commits, --stdin-packs, or neither) unless the new "--additive" argument is specified.
Thanks, Stefan