From: "Ævar Arnfjörð Bjarmason" <email@example.com> To: Jakub Narebski <firstname.lastname@example.org> Cc: email@example.com, Derrick Stolee <firstname.lastname@example.org>, Derrick Stolee <email@example.com>, Jeff King <firstname.lastname@example.org> Subject: Re: [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc. Date: Fri, 04 May 2018 22:07:42 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Fri, May 04 2018, Jakub Narebski wrote: > With early parts of commit-graph feature (ds/commit-graph and > ds/lazy-load-trees) close to being merged into "master", see > https://email@example.com/ > I think it would be good idea to think what other data could be added > there to make Git even faster. Thanks for the write-up. > 3. Third, it needs to be reasonably fast to create, and fast to update. > This means time to create the chunk to be proportional to number of > commits, or sum of number of commits and edges (which for commit graph > and other sparse graphs is proprtional to the number of nodes / commits > anyway). In my opinion time proportional to n*lug(n), where 'n' is the > number of commits, is also acceptable. Times proportional to n^2 or n^3 > are not acceptable. I don't think this requirement makes sense... > DS> If we add commit-graph file downloads to the protocol, then the > DS> server could do this computation and send the data to all > DS> clients. But that would be "secondary" information that maybe > DS> clients want to verify, which is as difficult as computing it > DS> themselves. ... when combined with this. If hypothetically there was some data that significantly sped up Git and the algorithm to generate it was ridiculously expensive, that would be fine when combined with the ability to fetch it pre-generated from the server. There could always be an option where you trust the server and optionally don't verify the data, or where it's much cheaper to verify than compute.
next prev parent reply other threads:[~2018-05-04 20:07 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-04 19:40 Jakub Narebski 2018-05-04 20:07 ` Ævar Arnfjörð Bjarmason [this message] 2018-05-04 20:36 ` Ævar Arnfjörð Bjarmason 2018-05-05 13:28 ` Jakub Narebski 2018-05-06 23:55 ` [RFC] Other chunks for commit-graph, part 2 - reachability indexes Jakub Narebski 2018-05-07 14:26 ` [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc Derrick Stolee 2018-05-12 14:00 ` Jakub Narebski 2018-05-14 13:20 ` Derrick Stolee 2018-05-14 20:58 ` Jakub Narebski 2018-05-15 10:01 ` Johannes Schindelin
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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC] Other chunks for commit-graph, part 1 - Bloom filters, topo order, etc.' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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 read-only IMAP folder(s) and NNTP newsgroup(s).