git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 3/5] repack: add --sparse and pass to pack-objects

From
Derrick Stolee <stolee@gmail.com>
Date
Jun 24, 2019, 13:03 UTC
Message-ID
<25cd9bcb-9b8f-662c-75d2-a5b32d7febbc@gmail.com>
In-Reply-To
<20190624120711.27744-4-nwf20@cl.cam.ac.uk>
On 6/24/2019 8:07 AM, Nathaniel Filardo wrote:
> The sparse connectivity algorithm saves a whole lot of time when there
> are UNINTERESTING trees around.
Neat! Any chance for some example performance stats?
> ---
Looks like you forgot your Signed-off-by here.
Show 5 quoted lines
> +# repack --sparse invokes pack-objects --sparse
> +test_expect_success 'repack --sparse and fsck' '
> +	git repack -a --sparse &&
> +	git fsck
> +'

This test may not be enough to properly test the sparse algorithm, as it is only really enabled when the --revs argument is given to the pack-objects process AND there is a "NOT" ref (i.e. "!{oid}" over stdin). Using "-a" here will not have any "NOT" references. OR maybe this already is enough when you have the .keep packs. Is there a way you could set up the packs in this test to explicitly be in the situation you describe where the sparse option speeds things up?

It's hard to check that the '--sparse' option is doing anything in a test, but it is important that we run the logic. One way to see if this test is doing anything is to insert a die() somewhere. For example, this die() statement will check if we ever needed to mark things uninteresting in a workdir path with both UNINTERESTING and INTERESTING trees:

diff --git a/revision.c b/revision.c
index eb8e51bc63..8835f8e7b1 100644
--- a/revision.c
+++ b/revision.c
@@ -227,6 +227,7 @@ void mark_trees_uninteresting_sparse(struct repository *r,
        if (!has_uninteresting || !has_interesting)
                return;

+       die("we exercised the logic!");
        paths_and_oids_init(&map);

        oidset_iter_init(trees, &iter);

The implementation of the argument looks straight-forward.
It appears we are passing the argument to the sub-process,
so the bitflag isn't used yet.

-Stolee
Previous: Nathaniel FilardoNext: Nathaniel Filardo
Message 6 of 11 in “Speed up repacking when lots of pack-kept objects”
  1. 0/5 Speed up repacking when lots of pack-kept objectsNathaniel Filardo, Jun 24, 2019
  2. 4/5 repack: optionally assume transitive kept packsNathaniel Filardo, Jun 24, 2019
  3. Derrick StoleeJun 24, 2019
  4. Dr N.W. FilardoJun 25, 2019
  5. 3/5 repack: add --sparse and pass to pack-objectsNathaniel Filardo, Jun 24, 2019
  6. Derrick StoleeJun 24, 2019
  7. 2/5 revision walk: optionally use sparse reachabilityNathaniel Filardo, Jun 24, 2019
  8. Derrick StoleeJun 24, 2019
  9. 1/5 count-objects: report statistics about kept packsNathaniel Filardo, Jun 24, 2019
  10. Derrick StoleeJun 24, 2019
  11. 5/5 builtin/gc: add --assume-pack-keep-transitiveNathaniel Filardo, Jun 24, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.