Re: ds/generation-numbers (was Re: What's cooking in git.git (Jun 2018, #01; Fri, 1))
On 6/1/2018 7:15 PM, Junio C Hamano wrote: Derrick Stolee writes: A recently added "commit-graph" datafile has learned to store pre-computed generation numbers to speed up the decisions to stop history traversal. Will cook in 'next'. On Wednesday, these were marked as "Will merge to 'master'" What changed? Nothing has changed. "Will merge to 'master'" means "This is now in 'next', and unless there is some blocking breakage found, this topic will be merged to 'master' eventually". It does not even say if that eventuality is before or after the release the current cycle is working towards. When it comes near pre-release feature freeze, things in 'next' need to be sifted into various bins, and their labels are updated. The ones that are too big to be comfortably merged to the upcoming release after -rc0 has passed (i.e. biggies are better merged early to the 'master' in the cycle to give it full cycle of larger exposure) will be kept in 'next' so that it can go first after the final, the ones that are low risk but with higher importance will be merged to 'master' before the release, the ones that are trivial, distracting and lower value (i.e. the ones that force i18n teams extra work) may be held in 'next', and the ones that deserve a chance to freshly restart are marked to be kicked back to 'pu'. Etc. etc. Thanks, Junio. This explanation is what I expected. I suppose the small extra bit of information of "Will cook in 'next' until after next release" would have answered my question in advance. Thanks for the patience as I get used to your workflow. I am a little disappointed this didn't make 2.18 because this gives some of the biggest speedups for typically painful computations (like 'git branch --contains'). The generation numbers are what give us more than a constant-multiple speedup; what is in master only parses commit relationships faster, doesn't reduce the number of commits walked. It also means we will release a version of Git that writes commit-graph file with GENERATION_ZERO and so we will never be able to deprecate that logic in the code. Thanks, -Stolee
Re: ds/generation-numbers (was Re: What's cooking in git.git (Jun 2018, #01; Fri, 1))
Derrick Stolee writes: >> A recently added "commit-graph" datafile has learned to store >> pre-computed generation numbers to speed up the decisions to stop >> history traversal. >> >> Will cook in 'next'. > > On Wednesday, these were marked as "Will merge to 'master'" What changed? Nothing has changed. "Will merge to 'master'" means "This is now in 'next', and unless there is some blocking breakage found, this topic will be merged to 'master' eventually". It does not even say if that eventuality is before or after the release the current cycle is working towards. When it comes near pre-release feature freeze, things in 'next' need to be sifted into various bins, and their labels are updated. The ones that are too big to be comfortably merged to the upcoming release after -rc0 has passed (i.e. biggies are better merged early to the 'master' in the cycle to give it full cycle of larger exposure) will be kept in 'next' so that it can go first after the final, the ones that are low risk but with higher importance will be merged to 'master' before the release, the ones that are trivial, distracting and lower value (i.e. the ones that force i18n teams extra work) may be held in 'next', and the ones that deserve a chance to freshly restart are marked to be kicked back to 'pu'. Etc. etc.
Re: What's cooking in git.git (Jun 2018, #01; Fri, 1)
> * jm/cache-entry-from-mem-pool (2018-05-24) 7 commits > - block alloc: add validations around cache_entry lifecyle > - block alloc: allocate cache entries from mem_pool > - mem-pool: fill out functionality > - mem-pool: add lifecycle management functions > - mem-pool: only search head block for available space > - block alloc: add lifecycle APIs for cache_entry structs > - read-cache: teach refresh_cache_entry() to take istate > > For a large tree, the index needs to hold many cache entries > allocated on heap. These cache entries are now allocated out of a > dedicated memory pool to amortize malloc(3) overhead. > > Is this ready for 'next'? https://public-inbox.org/git/CAGZ79kZ-1jwnhzZrCeoZTZrNSwmnO=6asWQgWXRj7tjfYVr=-a...@mail.gmail.com/ I wanted to give it one final read, as Jameson mentioned to he might resend addressing questions from the last round. I think it is not quite there yet. > * sb/object-store-grafts (2018-05-18) 19 commits [...] > (this branch uses sb/object-store-alloc.) > > The conversion to pass "the_repository" and then "a_repository" > throughout the object access API continues. > > Will merge to and cook in 'next'. > * sb/object-store-alloc (2018-05-16) 13 commits [...] > - repository: introduce parsed objects field > (this branch is used by sb/object-store-grafts.) > > The conversion to pass "the_repository" and then "a_repository" > throughout the object access API continues. > > Will merge to and cook in 'next'. Thanks. Should I continue to build on top of these series or merge in side branches to have a newer base? c.f. https://public-inbox.org/git/20180530004810.30076-1-sbel...@google.com/ > * sb/diff-color-move-more (2018-05-21) 8 commits [...] > "git diff --color-moved" feature has further been tweaked. > > Will kick back to 'pu'. > cf. I hope to get this out again, today.
ds/generation-numbers (was Re: What's cooking in git.git (Jun 2018, #01; Fri, 1))
On 6/1/2018 3:21 AM, Junio C Hamano wrote: * ds/commit-graph-lockfile-fix (2018-05-22) 1 commit (merged to 'next' on 2018-05-24 at 3d12a02b0c) + commit-graph: fix UX issue when .lock file exists (this branch is used by ds/commit-graph-fsck; uses ds/generation-numbers.) Update to ds/generation-numbers topic. Wait for ds/generation-numbers * ds/generation-numbers (2018-05-22) 11 commits (merged to 'next' on 2018-05-24 at 56fc38a1b6) + commit-graph.txt: update design document + merge: check config before loading commits + commit: use generation number in remove_redundant() + commit: add short-circuit to paint_down_to_common() + commit: use generation numbers for in_merge_bases() + ref-filter: use generation number for --contains + commit-graph: always load commit-graph information + commit: use generations in paint_down_to_common() + commit-graph: compute generation numbers + commit: add generation number to struct commit + ref-filter: fix outdated comment on in_commit_list (this branch is used by ds/commit-graph-fsck and ds/commit-graph-lockfile-fix.) A recently added "commit-graph" datafile has learned to store pre-computed generation numbers to speed up the decisions to stop history traversal. Will cook in 'next'. On Wednesday, these were marked as "Will merge to 'master'" What changed? Thanks, -Stolee
