From: Son Luong Ngoc <firstname.lastname@example.org> To: email@example.com Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH 3/3] commit-graph: respect 'core.useBloomFilters' Date: Wed, 1 Jul 2020 11:58:53 +0200 [thread overview] Message-ID: <CAL3xRKdZyE+9r-bPTDo_Fiz=nT_Y7uve+rvBqQZxjL-DYMGYpw@mail.gmail.com> (raw) Hi folks, On Tue, 30 Jun 2020 15:33:40 -0400, Jeff King wrote: > > > It might even be worth considering whether "changed paths" needs more > > > context (or would if we add new features in the future). On a "git > > > commit-graph write" command-line it is perfectly clear, but would > > > core.commitGraphChangedPaths be worth it? It's definitely more specific, > > > but it's also way more ugly. ;) > > > > Here's a third option what about 'graph.readChangedPaths'. I think that > > Stolee and I discussed a new top-level 'graph' section, since we now > > have a few commit-graph-related configuration variables in 'core'. > > Yes, I like that even better. Probably "graph" is sufficiently specific > within Git's context, though I guess it _could_ bring to mind "git log > --graph". So many overloaded terms. :) I would suggest using 'commitgraph.readChangedPaths' as I was planning on implementing the same config in  but never got around to it. From an end-user perspective, not server admin, 'graph' is very much correlated to 'git log --graph'. Using 'commitgraph' instead of core could also help us enabling more config down the line that equate to the current options in 'git commit-graph write'. I.e. something like 'commitgraph.writeSplit' might be desirable to tune the behavior of 'gc.writeCommitGraph' to use '--split=replace' strategy. --- @Taylor: Thanks a lot for implementing this. On Tue, 30 Jun 2020 13:17:36 -0400, Taylor Blau wrote: > We're planning on using these patches as part of a two-phase roll-out of > changed-path Bloom filters, where the first phase conditions whether or > not repositories *write* Bloom filters, and the second phase (controlled > via the new 'core.useBloomFilters') controls whether repositories *read* > their Bloom filters. Could you elaborate a bit more on the 'two-phase roll-out' mentioned here? I was looking for a way to verify whether a commit-graph chain has been written with Bloom filter (and force it to rewrite if not) but there seems to be no straightforward way? Do we need to implement a flag in 'git commit-graph verify' to check for Bloom filter existence? : https://github.com/gitgitgadget/git/pull/633 Regards, Son Luong.
next reply other threads:[~2020-07-01 9:59 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-01 9:58 Son Luong Ngoc [this message] 2020-07-13 19:22 ` Taylor Blau -- strict thread matches above, loose matches on Subject: below -- 2020-06-30 17:17 [PATCH 0/3] commit-graph: introduce 'core.useBloomFilters' Taylor Blau 2020-06-30 17:17 ` [PATCH 3/3] commit-graph: respect 'core.useBloomFilters' Taylor Blau 2020-06-30 19:18 ` Jeff King 2020-06-30 19:27 ` Taylor Blau 2020-06-30 19:33 ` Jeff King
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 \ --in-reply-to='CAL3xRKdZyE+9r-bPTDo_Fiz=nT_Y7uve+rvBqQZxjL-DYMGYpw@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 3/3] commit-graph: respect '\''core.useBloomFilters'\''' \ /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).