Re: [PATCH 0/5] Partial bundle follow ups

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 23, 2022, 21:27 UTC
Message-ID: <xmqqlex0qrz7.fsf@gitster.g>
In-Reply-To: <pull.1186.git.1647970119.gitgitgadget@gmail.com>

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 9 quoted lines

> This is based on master, which recently took ds/partial-bundles.
>
> There are a couple conflicts with 'seen':
>
>  * rc/fetch-refetch adds the "--refetch" option right next to where I remove
>    an instance of CL_ARG__FILTER.
>  * tb/cruft-packs updates the add_unseen_recent_objects_to_traversal()
>    method, but this series changes one call from using "&revs" to using
>    "revs".

Demonstrating that the submitter has already made an effort to make sure the new topic plays well with other topics in flight this way is very much appreciated.

Show 8 quoted lines

> These are a few cleanups that were discussed as part of ds/partial-bundles.
>
>  * Patch 1 removes the CL_ARG__FILTER macro.
>  * Patches 2-3 help parse --filter directly into a revs.filter member
>    instead of copying it from another filter_options.
>  * Patches 4-5 add output of the hash function capability in 'git bundle
>    verify'. It also moves the capability output to the end, since it looks a
>    bit strange in the current location when there are boundary commits.

OK.

Show 7 quoted lines

>  * create_bundle() in bundle.c does two commit walks: first to discover the
>    boundary commits to write into the bundle header, and then another that
>    happens when constructing the pack-file. It looks like this could be
>    avoided if there will not be any boundary, but there are additional
>    checks in write_bundle_refs() that look for the SHOWN bit on the commit
>    objects in order to determine if a requested ref would be excluded by the
>    rev-list options. This behavior seems important, so I did not remove it.

Good thinking.  Thanks.

Show 5 quoted lines

>  * 'git clone --bare partial.bdl" should work when partial.bdl is a partial
>    bundle. However, this requires changing the way we configure partial
>    cloned repositories to not rely on a remote in order to understand an
>    object filter. I'm working on this as a parallel series that will likely
>    require more discussion than these small cleanups.

Leaving it outside the topic, saying that you cannot yet clone from such a bundle, is perfectly fine, I would think. Thanks.

>  * Ævar pointed out some newly-visible memory leaks due to moving the filter
>    out of a static global. After looking at the recommended change, it seems
>    that we actually need to be more careful about freeing the revs and not
>    just revs.filter.

OK.