From: Jakub Narebski <jnareb@gmail.com> To: "Garima Singh via GitGitGadget" <gitgitgadget@gmail.com> Cc: git@vger.kernel.org, "Derrick Stolee" <stolee@gmail.com>, "SZEDER Gábor" <szeder.dev@gmail.com>, "Jonathan Tan" <jonathantanmy@google.com>, "Jeff Hostetler" <jeffhost@microsoft.com>, "Taylor Blau" <me@ttaylorr.com>, "Jeff King" <peff@peff.net>, "Junio C Hamano" <gitster@pobox.com>, "Garima Singh" <garima.singh@microsoft.com> Subject: Re: [PATCH 7/9] commit-graph: reuse existing bloom filters during write. Date: Thu, 09 Jan 2020 20:12:07 +0100 [thread overview] Message-ID: <86r208v3zs.fsf@gmail.com> (raw) In-Reply-To: <1e2acb37ad710cb0d1c09ed163fdd4473a27335c.1576879520.git.gitgitgadget@gmail.com> (Garima Singh via GitGitGadget's message of "Fri, 20 Dec 2019 22:05:18 +0000") "Garima Singh via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Garima Singh <garima.singh@microsoft.com> > Overly long lines in the commit message. > Read previously computed bloom filters from the commit-graph file if possible > to avoid recomputing during commit-graph write. Hmmm. This fixes (somewhat) the problem that I have noticed in previous patch that the Bloom filter was computed at least twice, once for BIDX chunk, once fo BDAT chunk. I think the order should be: - use Bloom filter on slab, if present - fill it from commit graph, if saved there - if needed, compute it from scratch (expensive operation!) If I understand it correctly, it now does it... though possibly with unnecessary memory allocation if commit-graph file does not include Bloomm filters data, and (re)computing is not requested (see later). But I might be wrong here. > > Reading from the commit-graph is based on the format in which bloom filters are > written in the commit graph file. See method `fill_filter_from_graph` in bloom.c This description reads a bit strange; it looks like it states a truism (we read in the format we wrote). It think it should be rephrased in different way for better readability. > > For reading the bloom filter for commit at lexicographic position i: I think it would better read as: To read Bloom filter for a given commit with lexicographic position 'i' we need to: > 1. Read BIDX[i] which essentially gives us the starting index in BDAT for filter > of commit i+1 (called the next_index in the code) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | \- I think would be not needed with better var name I would also add that it gives the position [one past] the end of Bloom filter data for i-th commit. > > 2. For i>0, read BIDX[i-1] which will give us the starting index in BDAT for > filter of commit i (called the prev_index in the code) Minor nitpick: Full stops are missing. Why it is called prev_index and next_index, while it is either curr_index and next_index or prev_index and curr_index, or maybe even better beg_index and end_index? > For i = 0, prev_index will be 0. The first lexicographic commit's filter will > start at BDAT. I would state it For first commit, with i = 0, Bloom filter data starts at the beginning, just past the header in BDAT chunk. > > 3. The length of the filter will be next_index - prev_index, because BIDX[i] > gives the cumulative 8-byte words including the ith commit's filter. > > We toggle whether bloom filters should be recomputed based on the compute_if_null > flag. All right. > > Helped-by: Derrick Stolee <dstolee@microsoft.com> > Signed-off-by: Garima Singh <garima.singh@microsoft.com> > --- > bloom.c | 40 ++++++++++++++++++++++++++++++++++++++-- > bloom.h | 3 ++- > commit-graph.c | 6 +++--- > 3 files changed, 43 insertions(+), 6 deletions(-) > > diff --git a/bloom.c b/bloom.c > index 08328cc381..86b1005802 100644 > --- a/bloom.c > +++ b/bloom.c > @@ -1,5 +1,7 @@ > #include "git-compat-util.h" > #include "bloom.h" > +#include "commit.h" > +#include "commit-slab.h" > #include "commit-graph.h" > #include "object-store.h" > #include "diff.h" > @@ -119,13 +121,35 @@ static void add_key_to_filter(struct bloom_key *key, > } > } > > +static void fill_filter_from_graph(struct commit_graph *g, > + struct bloom_filter *filter, > + struct commit *c) > +{ > + uint32_t lex_pos, prev_index, next_index; > + > + while (c->graph_pos < g->num_commits_in_base) > + g = g->base_graph; > + > + lex_pos = c->graph_pos - g->num_commits_in_base; This part shares common code with load_oid_from_graph(), only without some of error checking; perhaps it might be good to extract it into a separate helper function, e.g. `lex_index(&g, c->graph_pos)`. Minor nitpick about the consistency of function names: why load_oid_from_graph(), but fill_filter_from_graph(), and not load_filter_from_graph() / load_bloom_from_graph()? > + > + next_index = get_be32(g->chunk_bloom_indexes + 4 * lex_pos); > + if (lex_pos) I think using + if (lex_pos > 0) or + if (lex_pos >= 0) might be easier to reason about. > + prev_index = get_be32(g->chunk_bloom_indexes + 4 * (lex_pos - 1)); > + else > + prev_index = 0; > + > + filter->len = next_index - prev_index; The above command reads a bit strange: next - prev? not next - curr, or curr - prev? Wouldn't it be better to name it begin_index and end_index, or beg_index and end_index for brevity? > + filter->data = (uint64_t *)(g->chunk_bloom_data + 8 * prev_index + 12); Please do not use magic constants; use instead something like: + filter->data = (uint64_t *)(g->chunk_bloom_data + + sizeof(uint64_t) * prev_index + + BLOOMDATA_CHUNK_HEADER_SIZE); Perhaps using `3*sizeof(unit32_t)` instead of magic value 12 would be enough; but having symbolic name for BDAT chunk header size is better, I think. > +} > + > void load_bloom_filters(void) > { > init_bloom_filter_slab(&bloom_filters); > } > > struct bloom_filter *get_bloom_filter(struct repository *r, > - struct commit *c) > + struct commit *c, > + int compute_if_null) I'm not sure about `compute_if_null` name... > { > struct bloom_filter *filter; > struct bloom_filter_settings settings = DEFAULT_BLOOM_FILTER_SETTINGS; > @@ -134,6 +158,18 @@ struct bloom_filter *get_bloom_filter(struct repository *r, > const char *revs_argv[] = {NULL, "HEAD", NULL}; > > filter = bloom_filter_slab_at(&bloom_filters, c); Note that the documentation for `slab_at(slab, commit)` is documented in `commit-slab.h` as * This function locates the data associated with the given commit in * the indegree slab, and returns the pointer to it. The location to * store the data is allocated as necessary. ~~~~~~~~~~~~~~~~~~~~~~ Should we worry about this possibly unnecessary allocation (if there is no Bloom filter chunk in the commit-graph, and we are not recomputing it)? There is `slab_peek(slab_commit)` with the following properties: * This function is similar to indegree_at(), but it will return NULL * until a call to indegree_at() was made for the commit. > + > + if (!filter->data) { What does the Bloom filter for a commit with no changes looks like? What about for a commit with more than 512 changes? Do, in either of those cases, filter->len is 0? If yes, what about filter->data? > + load_commit_graph_info(r, c); > + if (c->graph_pos != COMMIT_NOT_FROM_GRAPH && r->objects->commit_graph->chunk_bloom_indexes) { Please wrap overly long lines (109 characters seems too long; the CodingGuidelines states: - We try to keep to at most 80 characters per line. + if (c->graph_pos != COMMIT_NOT_FROM_GRAPH && + r->objects->commit_graph->chunk_bloom_indexes) { You seem to assume here that in the chain of commit-graph files either all of them would have Bloom filters, or all of them would be missing Bloom filters. Isn't it however possible for only some of the commit-graph files in chain to include Bloom filter data chunks? In such case, the top commit-graph file may have BIDX chunk (bloom_indexes), but the commit-graph with the commit 'c' might not have it. Or the top commit-graph file may be missing BIDX chunk, so Git would recompute it even if the commit-graph file for commit 'c' includes it. If such situation is forbidden, how the restriction is managed? Note: in any case, this needs to be tested! > + fill_filter_from_graph(r->objects->commit_graph, filter, c); > + return filter; > + } > + } All right, if it is not in slab, we try to read if from the commit graph. Looks all right. > + > + if (filter->data || !compute_if_null) > + return filter; ^^^^^^^^ | \- one tab too many If we have found existing filter (on slab or in the commit-graph), or if we won't be recomputing it, return it. O.K. > + > init_revisions(&revs, NULL); > revs.diffopt.flags.recursive = 1; > > @@ -198,4 +234,4 @@ struct bloom_filter *get_bloom_filter(struct repository *r, > DIFF_QUEUE_CLEAR(&diff_queued_diff); > > return filter; > -} > \ No newline at end of file > +} Accidental change. > diff --git a/bloom.h b/bloom.h > index ba8ae70b67..101d689bbd 100644 > --- a/bloom.h > +++ b/bloom.h > @@ -36,7 +36,8 @@ struct bloom_key { > void load_bloom_filters(void); > > struct bloom_filter *get_bloom_filter(struct repository *r, > - struct commit *c); > + struct commit *c, > + int compute_if_null); > All right, this is just update of the function signature. > void fill_bloom_key(const char *data, > int len, > diff --git a/commit-graph.c b/commit-graph.c > index def2ade166..0580ce75d5 100644 > --- a/commit-graph.c > +++ b/commit-graph.c > @@ -1032,7 +1032,7 @@ static void write_graph_chunk_bloom_indexes(struct hashfile *f, > uint32_t cur_pos = 0; > > while (list < last) { > - struct bloom_filter *filter = get_bloom_filter(ctx->r, *list); > + struct bloom_filter *filter = get_bloom_filter(ctx->r, *list, 0); > cur_pos += filter->len; > hashwrite_be32(f, cur_pos); > list++; > @@ -1051,7 +1051,7 @@ static void write_graph_chunk_bloom_data(struct hashfile *f, > hashwrite_be32(f, settings->bits_per_entry); > > while (first < last) { > - struct bloom_filter *filter = get_bloom_filter(ctx->r, *first); > + struct bloom_filter *filter = get_bloom_filter(ctx->r, *first, 0); > hashwrite(f, filter->data, filter->len * sizeof(uint64_t)); > first++; > } O.K., so those two do not compute Bloom filters, but they are called from write_commit_graph_file(), which in turn is called in write_commit_graph() *after* running compute_bloom_filters(). Looks good to me, then. > @@ -1218,7 +1218,7 @@ static void compute_bloom_filters(struct write_commit_graph_context *ctx) > > for (i = 0; i < ctx->commits.nr; i++) { > struct commit *c = ctx->commits.list[i]; > - struct bloom_filter *filter = get_bloom_filter(ctx->r, c); > + struct bloom_filter *filter = get_bloom_filter(ctx->r, c, 1); > ctx->total_bloom_filter_size += sizeof(uint64_t) * filter->len; > display_progress(progress, i + 1); > } All right, so compute_bloom_filters() ensures that it is actually computed (if needed). Looks good to me. Regards, -- Jakub Narębski
next prev parent reply other threads:[~2020-01-09 19:12 UTC|newest] Thread overview: 159+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-20 22:05 [PATCH 0/9] [RFC] Changed Paths Bloom Filters Garima Singh via GitGitGadget 2019-12-20 22:05 ` [PATCH 1/9] commit-graph: add --changed-paths option to write Garima Singh via GitGitGadget 2020-01-01 20:20 ` Jakub Narebski 2019-12-20 22:05 ` [PATCH 2/9] commit-graph: write changed paths bloom filters Garima Singh via GitGitGadget 2019-12-21 16:48 ` Philip Oakley 2020-01-06 18:44 ` Jakub Narebski 2020-01-13 19:48 ` Garima Singh 2019-12-20 22:05 ` [PATCH 3/9] commit-graph: use MAX_NUM_CHUNKS Garima Singh via GitGitGadget 2020-01-07 12:19 ` Jakub Narebski 2019-12-20 22:05 ` [PATCH 4/9] commit-graph: document bloom filter format Garima Singh via GitGitGadget 2020-01-07 14:46 ` Jakub Narebski 2019-12-20 22:05 ` [PATCH 5/9] commit-graph: write changed path bloom filters to commit-graph file Garima Singh via GitGitGadget 2020-01-07 16:01 ` Jakub Narebski 2020-01-14 15:14 ` Garima Singh 2019-12-20 22:05 ` [PATCH 6/9] commit-graph: test commit-graph write --changed-paths Garima Singh via GitGitGadget 2020-01-08 0:32 ` Jakub Narebski 2019-12-20 22:05 ` [PATCH 7/9] commit-graph: reuse existing bloom filters during write Garima Singh via GitGitGadget 2020-01-09 19:12 ` Jakub Narebski [this message] 2019-12-20 22:05 ` [PATCH 8/9] revision.c: use bloom filters to speed up path based revision walks Garima Singh via GitGitGadget 2020-01-11 0:27 ` Jakub Narebski 2020-01-15 0:08 ` Garima Singh 2019-12-20 22:05 ` [PATCH 9/9] commit-graph: add GIT_TEST_COMMIT_GRAPH_BLOOM_FILTERS test flag Garima Singh via GitGitGadget 2020-01-11 19:56 ` Jakub Narebski 2020-01-15 0:55 ` Garima Singh 2019-12-20 22:14 ` [PATCH 0/9] [RFC] Changed Paths Bloom Filters Junio C Hamano 2019-12-22 9:26 ` Christian Couder 2019-12-22 9:38 ` Jeff King 2020-01-01 12:04 ` Jakub Narebski 2019-12-22 9:30 ` Jeff King 2019-12-22 9:32 ` [PATCH 1/3] commit-graph: examine changed-path objects in pack order Jeff King 2019-12-27 14:51 ` Derrick Stolee 2019-12-29 6:12 ` Jeff King 2019-12-29 6:28 ` Jeff King 2019-12-30 14:37 ` Derrick Stolee 2019-12-30 14:51 ` Derrick Stolee 2019-12-22 9:32 ` [PATCH 2/3] commit-graph: free large diffs, too Jeff King 2019-12-27 14:52 ` Derrick Stolee 2019-12-22 9:32 ` [PATCH 3/3] commit-graph: stop using full rev_info for diffs Jeff King 2019-12-27 14:53 ` Derrick Stolee 2019-12-26 14:21 ` [PATCH 0/9] [RFC] Changed Paths Bloom Filters Derrick Stolee 2019-12-29 6:03 ` Jeff King 2019-12-27 16:11 ` Derrick Stolee 2019-12-29 6:24 ` Jeff King 2019-12-30 16:04 ` Derrick Stolee 2019-12-30 17:02 ` Junio C Hamano 2019-12-31 16:45 ` Jakub Narebski 2020-01-13 16:54 ` Garima Singh 2020-01-20 13:48 ` Jakub Narebski 2020-01-21 16:14 ` Garima Singh 2020-02-02 18:43 ` Jakub Narebski 2020-01-21 23:40 ` Emily Shaffer 2020-01-27 18:24 ` Garima Singh 2020-02-01 23:32 ` Jakub Narebski 2020-02-05 22:56 ` [PATCH v2 00/11] " Garima Singh via GitGitGadget 2020-02-05 22:56 ` [PATCH v2 01/11] commit-graph: use MAX_NUM_CHUNKS Garima Singh via GitGitGadget 2020-02-09 12:39 ` Jakub Narebski 2020-02-05 22:56 ` [PATCH v2 02/11] bloom: core Bloom filter implementation for changed paths Garima Singh via GitGitGadget 2020-02-15 17:17 ` Jakub Narebski 2020-02-16 16:49 ` Jakub Narebski 2020-02-22 0:32 ` Garima Singh 2020-02-23 13:38 ` Jakub Narebski 2020-02-24 17:34 ` Garima Singh 2020-02-24 18:20 ` Jakub Narebski 2020-02-05 22:56 ` [PATCH v2 03/11] diff: halt tree-diff early after max_changes Derrick Stolee via GitGitGadget 2020-02-17 0:00 ` Jakub Narebski 2020-02-22 0:37 ` Garima Singh 2020-02-05 22:56 ` [PATCH v2 04/11] commit-graph: compute Bloom filters for changed paths Garima Singh via GitGitGadget 2020-02-17 21:56 ` Jakub Narebski 2020-02-22 0:55 ` Garima Singh 2020-02-23 17:34 ` Jakub Narebski 2020-02-05 22:56 ` [PATCH v2 05/11] commit-graph: examine changed-path objects in pack order Jeff King via GitGitGadget 2020-02-18 17:59 ` Jakub Narebski 2020-02-24 18:29 ` Garima Singh 2020-02-05 22:56 ` [PATCH v2 06/11] commit-graph: examine commits by generation number Derrick Stolee via GitGitGadget 2020-02-19 0:32 ` Jakub Narebski 2020-02-24 20:45 ` Garima Singh 2020-02-05 22:56 ` [PATCH v2 07/11] commit-graph: write Bloom filters to commit graph file Garima Singh via GitGitGadget 2020-02-19 15:13 ` Jakub Narebski 2020-02-24 21:14 ` Garima Singh 2020-02-25 11:40 ` Jakub Narebski 2020-02-25 15:58 ` Garima Singh 2020-02-05 22:56 ` [PATCH v2 08/11] commit-graph: reuse existing Bloom filters during write Garima Singh via GitGitGadget 2020-02-20 18:48 ` Jakub Narebski 2020-02-24 21:45 ` Garima Singh 2020-02-05 22:56 ` [PATCH v2 09/11] commit-graph: add --changed-paths option to write subcommand Garima Singh via GitGitGadget 2020-02-20 20:28 ` Jakub Narebski 2020-02-24 21:51 ` Garima Singh 2020-02-25 12:10 ` Jakub Narebski 2020-02-20 22:10 ` Bryan Turner 2020-02-22 1:44 ` Garima Singh 2020-02-05 22:56 ` [PATCH v2 10/11] revision.c: use Bloom filters to speed up path based revision walks Garima Singh via GitGitGadget 2020-02-21 17:31 ` Jakub Narebski 2020-02-21 22:45 ` Jakub Narebski 2020-02-05 22:56 ` [PATCH v2 11/11] commit-graph: add GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS test flag Garima Singh via GitGitGadget 2020-02-22 0:11 ` Jakub Narebski 2020-02-07 13:52 ` [PATCH v2 00/11] Changed Paths Bloom Filters SZEDER Gábor 2020-02-07 15:09 ` Garima Singh 2020-02-07 15:36 ` Derrick Stolee 2020-02-07 16:15 ` SZEDER Gábor 2020-02-07 16:33 ` Derrick Stolee 2020-02-11 19:08 ` Garima Singh 2020-02-08 23:04 ` Jakub Narebski 2020-02-21 17:41 ` Garima Singh 2020-03-29 18:36 ` Junio C Hamano 2020-03-30 0:31 ` [PATCH v3 00/16] " Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 01/16] commit-graph: define and use MAX_NUM_CHUNKS Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 02/16] bloom.c: add the murmur3 hash implementation Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 03/16] bloom.c: introduce core Bloom filter constructs Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 04/16] bloom.c: core Bloom filter implementation for changed paths Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 05/16] diff: halt tree-diff early after max_changes Derrick Stolee via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 06/16] commit-graph: compute Bloom filters for changed paths Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 07/16] commit-graph: examine changed-path objects in pack order Jeff King via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 08/16] commit-graph: examine commits by generation number Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 09/16] diff: skip batch object download when possible Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 10/16] commit-graph: write Bloom filters to commit graph file Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 11/16] commit-graph: reuse existing Bloom filters during write Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 12/16] commit-graph: add --changed-paths option to write subcommand Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 13/16] revision.c: use Bloom filters to speed up path based revision walks Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 14/16] revision.c: add trace2 stats around Bloom filter usage Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 15/16] t4216: add end to end tests for git log with Bloom filters Garima Singh via GitGitGadget 2020-03-30 0:31 ` [PATCH v3 16/16] commit-graph: add GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS test flag Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 00/15] Changed Paths Bloom Filters Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 01/15] commit-graph: define and use MAX_NUM_CHUNKS Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 02/15] bloom.c: add the murmur3 hash implementation Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 03/15] bloom.c: introduce core Bloom filter constructs Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 04/15] bloom.c: core Bloom filter implementation for changed paths Garima Singh via GitGitGadget 2020-06-27 15:53 ` SZEDER Gábor 2020-04-06 16:59 ` [PATCH v4 05/15] diff: halt tree-diff early after max_changes Derrick Stolee via GitGitGadget 2020-08-04 14:47 ` SZEDER Gábor 2020-08-04 16:25 ` Derrick Stolee 2020-08-04 17:00 ` SZEDER Gábor 2020-08-04 17:31 ` Derrick Stolee 2020-08-05 17:08 ` Derrick Stolee 2020-04-06 16:59 ` [PATCH v4 06/15] commit-graph: compute Bloom filters for changed paths Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 07/15] commit-graph: examine changed-path objects in pack order Jeff King via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 08/15] commit-graph: examine commits by generation number Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 09/15] commit-graph: write Bloom filters to commit graph file Garima Singh via GitGitGadget 2020-05-29 8:57 ` SZEDER Gábor 2020-05-29 13:35 ` Derrick Stolee 2020-05-31 17:23 ` SZEDER Gábor 2020-07-09 17:00 ` [PATCH] commit-graph: fix "Writing out commit graph" progress counter SZEDER Gábor 2020-07-09 18:01 ` Derrick Stolee 2020-07-09 18:20 ` Derrick Stolee 2020-04-06 16:59 ` [PATCH v4 10/15] commit-graph: reuse existing Bloom filters during write Garima Singh via GitGitGadget 2020-06-19 14:02 ` SZEDER Gábor 2020-06-19 19:28 ` Junio C Hamano 2020-07-27 21:33 ` SZEDER Gábor 2020-04-06 16:59 ` [PATCH v4 11/15] commit-graph: add --changed-paths option to write subcommand Garima Singh via GitGitGadget 2020-06-07 22:21 ` SZEDER Gábor 2020-04-06 16:59 ` [PATCH v4 12/15] revision.c: use Bloom filters to speed up path based revision walks Garima Singh via GitGitGadget 2020-06-26 6:34 ` SZEDER Gábor 2020-04-06 16:59 ` [PATCH v4 13/15] revision.c: add trace2 stats around Bloom filter usage Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 14/15] t4216: add end to end tests for git log with Bloom filters Garima Singh via GitGitGadget 2020-04-06 16:59 ` [PATCH v4 15/15] commit-graph: add GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS test flag Garima Singh via GitGitGadget 2020-04-08 15:51 ` [PATCH v4 00/15] Changed Paths Bloom Filters Derrick Stolee 2020-04-08 19:21 ` Junio C Hamano 2020-04-08 20:05 ` Jakub Narębski 2020-04-12 20:34 ` Taylor Blau 2020-03-05 19:49 ` [PATCH 0/9] [RFC] " Garima Singh
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=86r208v3zs.fsf@gmail.com \ --to=jnareb@gmail.com \ --cc=garima.singh@microsoft.com \ --cc=git@vger.kernel.org \ --cc=gitgitgadget@gmail.com \ --cc=gitster@pobox.com \ --cc=jeffhost@microsoft.com \ --cc=jonathantanmy@google.com \ --cc=me@ttaylorr.com \ --cc=peff@peff.net \ --cc=stolee@gmail.com \ --cc=szeder.dev@gmail.com \ --subject='Re: [PATCH 7/9] commit-graph: reuse existing bloom filters during write.' \ /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).