On Mon, Feb 26, 2018 at 6:32 PM, Derrick Stolee <stolee@xxxxxxxxx> 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
