Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

pack-objects: allow --path-walk with --shallow #699

Merged
merged 4 commits into from
Oct 22, 2024
Merged

pack-objects: allow --path-walk with --shallow #699

merged 4 commits into from
Oct 22, 2024

Commits on Oct 22, 2024

  1. t5616: mark tests as bogus with --path-walk 

    These two tests in t5616-partial-clone.sh are actually already broken
and there are comments supporting that. Those comments were focused on
the GIT_TEST_FULL_NAME_HASH variable, but they also apply to this one.
We will want to avoid issues here.

Signed-off-by: Derrick Stolee <[email protected]>
    @derrickstolee
    derrickstolee committed Oct 22, 2024
    Configuration menu
    Copy the full SHA
    17ce490 View commit details
    Browse the repository at this point in the history

  2. path-walk: add new 'edge_aggressive' option 

    In preparation for allowing both the --shallow and --path-walk options
in the 'git pack-objects' builtin, create a new 'edge_aggressive' option
in the path-walk API. This option will help walk the boundary more
thoroughly and help avoid sending extra objects during fetches and
pushes.

The only use of the 'edge_hint_aggressive' option in the revision API is
within mark_edges_uninteresting(), which is usually called before
between prepare_revision_walk() and before visiting commits with
get_revision(). In prepare_revision_walk(), the UNINTERESTING commits
are walked until a boundary is found.

We didn't use this in the past because we would mark objects
UNINTERESTING after doing the initial commit walk to the boundary. While
we should be marking these objects as UNINTERESTING, we shouldn't _emit_
them all via the path-walk algorithm or else our delta calculations will
get really slow.

Based on these observations, the way we were handling the UNINTERESTING
flag in walk_objects_by_path() was overly complicated and buggy. A lot
of it can be removed and simplified to work with this new approach.

It also means that we will see the UNINTERESTING boundaries of paths
when doing a default path-walk call, changing some existing test cases.

Signed-off-by: Derrick Stolee <[email protected]>
    @derrickstolee
    derrickstolee committed Oct 22, 2024
    Configuration menu
    Copy the full SHA
    1af435e View commit details
    Browse the repository at this point in the history

  3. pack-objects: allow --shallow and --path-walk 

    There does not appear to be anything particularly incompatible about the
--shallow and --path-walk options of 'git pack-objects'. If shallow
commits are to be handled differently, then it is by the revision walk
that defines the commit set and which are interesting or uninteresting.

However, before the previous change, a trivial removal of the warning
would cause a failure in t5500-fetch-pack.sh when
GIT_TEST_PACK_PATH_WALK is enabled. The shallow fetch would provide more
objects than we desired, due to some incorrect behavior of the path-walk
API, especially around walking uninteresting objects.

To also cover the symmetrical case of pushing from a shallow clone, add
a new test to t5538-push-shallow.sh that confirms the correct behavior
of pushing only the new object. This works to validate both the
--path-walk and --no-path-walk case when toggling the
GIT_TEST_PACK_PATH_WALK environment variable. This test would have
failed in the --path-walk case if we created it before the previous
change.

Signed-off-by: Derrick Stolee <[email protected]>
    @derrickstolee
    derrickstolee committed Oct 22, 2024
    Configuration menu
    Copy the full SHA
    24c5b3a View commit details
    Browse the repository at this point in the history

  4. t5538: add test to confirm deltas in shallow pushes 

    It can be notoriously difficult to detect if delta bases are being
computed properly during 'git push'. Construct an example where it will
make a kilobyte worth of difference when a delta base is not found. We
can then use the progress indicators to distinguish between bytes and
KiB depending on whether the delta base is found and used.

Signed-off-by: Derrick Stolee <[email protected]>
    @derrickstolee
    derrickstolee committed Oct 22, 2024
    Configuration menu
    Copy the full SHA
    cec2f4a View commit details
    Browse the repository at this point in the history