From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>
Subject: Re: What's cooking in git.git (May 2018, #01; Mon, 7)
Date: Mon, 7 May 2018 11:20:09 -0400 [thread overview]
Message-ID: <1bb666a1-ce44-3eb0-e63c-a6a9e2a675dd@gmail.com> (raw)
In-Reply-To: <xmqqa7tbpl5q.fsf@gitster-ct.c.googlers.com>
On 5/7/2018 10:58 AM, Junio C Hamano wrote:
> * ds/generation-numbers (2018-05-02) 11 commits
> - 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 commmit
> - ref-filter: fix outdated comment on in_commit_list
> (this branch uses ds/commit-graph and ds/lazy-load-trees.)
>
> A recently added "commit-graph" datafile has learned to store
> pre-computed generation numbers to speed up the decisions to stop
> history traversal.
>
> Is this ready for 'next'?
I see that you squashed the fix from [1], so I think this is ready to
go. Thanks!
[1]
https://public-inbox.org/git/1cfe38f6-925b-d36b-53ae-6b586eed199c@gmail.com/
> * ds/lazy-load-trees (2018-05-02) 6 commits
> (merged to 'next' on 2018-05-02 at d54016d9e3)
> + coccinelle: avoid wrong transformation suggestions from commit.cocci
> (merged to 'next' on 2018-04-25 at b90813f421)
> + commit-graph: lazy-load trees for commits
> + treewide: replace maybe_tree with accessor methods
> + commit: create get_commit_tree() method
> + treewide: rename tree to maybe_tree
> + Merge branch 'bw/c-plus-plus' into ds/lazy-load-trees
> (this branch is used by ds/generation-numbers; uses ds/commit-graph.)
>
> The code has been taught to use the duplicated information stored
> in the commit-graph file to learn the tree object name for a commit
> to avoid opening and parsing the commit object when it makes sense
> to do so.
>
> Will merge to 'master'.
>
>
> * ds/commit-graph (2018-04-11) 16 commits
> (merged to 'next' on 2018-04-25 at 18af3d28d9)
> + commit-graph: implement "--append" 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/generation-numbers and ds/lazy-load-trees.)
>
> Precompute and store information necessary for ancestry traversal
> in a separate file to optimize graph walking.
>
> Will merge to 'master'.
These have been queued for master for a few weeks. Is anything delaying
them? I'd love to see the community dogfood this feature by running the
following on their local repos:
git config core.commitGraph true
git show-ref -s | git commit-graph write --stdin-commits
Thanks,
-Stolee
next prev parent reply other threads:[~2018-05-07 15:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-07 14:58 What's cooking in git.git (May 2018, #01; Mon, 7) Junio C Hamano
2018-05-07 15:20 ` Derrick Stolee [this message]
2018-05-07 16:33 ` Elijah Newren
2018-05-08 0:44 ` Junio C Hamano
2018-05-07 15:57 ` Elijah Newren
2018-05-08 1:01 ` Junio C Hamano
2018-05-08 17:05 ` Ben Peart
2018-05-10 4:25 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1bb666a1-ce44-3eb0-e63c-a6a9e2a675dd@gmail.com \
--to=stolee@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).