Re: tb/cruft-packs (was Re: What's cooking in git.git (Mar 2022, #01; Thu, 3))

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 7, 2022, 18:06 UTC
Message-ID: <YiZJiPVMZwPXbfrK@google.com>
In-Reply-To: <0870b8f0-976a-cf2f-f34f-7e966b9c426f@github.com>

Hi,

Derrick Stolee wrote:

> On 3/3/2022 11:31 PM, Junio C Hamano wrote:

Show 28 quoted lines

>> * tb/cruft-packs (2022-03-02) 17 commits
>>  - sha1-file.c: don't freshen cruft packs
>>  - builtin/gc.c: conditionally avoid pruning objects via loose
>>  - builtin/repack.c: add cruft packs to MIDX during geometric repack
>>  - builtin/repack.c: use named flags for existing_packs
>>  - builtin/repack.c: allow configuring cruft pack generation
>>  - builtin/repack.c: support generating a cruft pack
>>  - builtin/pack-objects.c: --cruft with expiration
>>  - reachable: report precise timestamps from objects in cruft packs
>>  - reachable: add options to add_unseen_recent_objects_to_traversal
>>  - builtin/pack-objects.c: --cruft without expiration
>>  - builtin/pack-objects.c: return from create_object_entry()
>>  - t/helper: add 'pack-mtimes' test-tool
>>  - pack-mtimes: support writing pack .mtimes files
>>  - chunk-format.h: extract oid_version()
>>  - pack-write: pass 'struct packing_data' to 'stage_tmp_packfiles'
>>  - pack-mtimes: support reading .mtimes files
>>  - Documentation/technical: add cruft-packs.txt
>>
>>  A mechanism to pack unreachable objects into a "cruft pack",
>>  instead of ejecting them into loose form to be reclaimed later, has
>>  been introduced.
>>
>>  Will merge to 'next'?
>>  source: <cover.1646266835.git.me@ttaylorr.com>
>
> This version looks good to me. There were some other comments that
> seem to have resolved without a need to change the patches.

I'm excited about this work! I just sent a quick review to the design doc.

Before merging to 'next', I'd be interested in two things:

 1. Marking the feature as experimental so we can learn from experience.
    Clarifying what aspects we consider to be stable / set in stone and
    what are subject to modification.

 2. Marking this as a repository format extension so it doesn't interact
    poorly with Git implementations (including older versions of Git
    itself) that are not aware of the new feature

Thoughts?

Thanks, Jonathan