"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > 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. > 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. > * 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. > * '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.
