[RFC] Bundle URIs Combined RFC #1234
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduce the idea of bundle URIs to the Git codebase through an aspirational design document. This document includes the full design intended to include the feature in its fully-implemented form. This will take several steps as detailed in the Implementation Plan section. By committing this document now, it can be used to motivate changes necessary to reach these final goals. The design can still be altered as new information is discovered. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
A future change will want a way to download a file over HTTP(S) using the simplest of download mechanisms. We do not want to assume that the server on the other side understands anything about the Git protocol but could be a simple static web server. Create the new 'get' capability for the remote helpers which advertises that the 'get' command is avalable. A caller can send a line containing 'get <url> <path>' to download the file at <url> into the file at <path>. RFC-TODO: This change requires tests directly on the remote helper. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Before implementing a way to fetch bundles into a repository, create the basic logic. Assume that the URI is actually a file path. Future logic will make this more careful to other protocols. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
The previous change created the logic for copying a file by name. Now, first inspect the URI for an HTTP(S) prefix and use git-remote-https as the way to download the data at that URI. Otherwise, check to see if file:// is present and modify the prefix accordingly. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Teach 'git fetch' a new --bundle-uri=<uri> option which changes the mode from fetching from a remote using the Git protocol to fetching a bundle from the given <uri>. See Documentation/technical/bundle-uri.txt for more information on the design of this feature. This implementation is limited to the most basic version of the feature. We expect the content at that URI to be a bundle file, not a bundle list. Bundle lists will be implemented later. This implementation is sufficient for a bundle provider to create a single bootstrap bundle for a large repository. The user would bootstrap a repository using a sequence of Git commands, such as: 1. git init <repo> && cd <repo> 2. git fetch --bundle-uri=<uri> 3. git remote add origin <url> 4. git fetch origin 5. git checkout FETCH_HEAD Later changes will make this seamless within a 'git clone' command, but this implementation is large enough to delay that integration. Currently, this option supports URIs using "http(s)://", "file://" or simply specifying a filename. Other protocols could be added in the future. RFC TODO: add end-to-end tests of this workflow. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
When fetching from a bundle URI, the branches of that bundle are stored in a different ref namespace: refs/bundles/. This namespace is intended to assist with later 'git fetch' negotiations with a Git server, allowing the client to advertise which data it already has from a bundle URI. These references can be confusing for a user when they appear as a decoration in 'git log' output. Add "refs/bundles/" to the multi-valued log.excludeDecoration config value. This is similar to the way "refs/prefetch/" is hidden by background prefetch operations in 'git maintenance' as added by 96eaffe (maintenance: set log.excludeDecoration durin prefetch, 2021-01-19). Signed-off-by: Derrick Stolee <derrickstolee@github.com>
derrickstolee
force-pushed
the
bundle-redo/rfc-3
branch
from
16928eb
to
82286f8
Compare
derrickstolee
changed the title
derrickstolee
force-pushed
the
bundle-redo/rfc-3
branch
2 times, most recently
from
d4165d8
to
e07e1c5
Compare
Cloning a remote repository is one of the most expensive operations in Git. The server can spend a lot of CPU time generating a pack-file for the client's request. The amount of data can clog the network for a long time, and the Git protocol is not resumable. For users with poor network connections or are located far away from the origin server, this can be especially painful. The 'git bundle fetch' command allows users to bootstrap a repository using a set of bundles. However, this would require them to use 'git init' first, followed by the 'git bundle fetch', and finally add a remote, fetch, and checkout the branch they want. Instead, integrate this workflow directly into 'git clone' with the --bundle-uri' option. If the user is aware of a bundle server, then they can tell Git to bootstrap the new repository with these bundles before fetching the remaining objects from the origin server. RFC-TODO: Document this option in git-clone.txt. RFC-TODO: I added a comment about the location of this code being necessary for the later step of auto-discovering the bundle URI from the origin server. This is probably not actually a requirement, but rather a pain point around how I implemented the feature. If a --bundle-uri option is specified, but SSH is used for the clone, then the SSH connection is left open while Git downloads bundles from another server. This is sub-optimal and should be reconsidered when fully reviewed. RFC-TODO: create tests for this option with a variety of URI types. RFC-TODO: a simple end-to-end test is available at the end of the series. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
The previous change added the '--bundle-uri' option, but did not check if the --depth parameter was included. Since bundles are not compatible with shallow clones, provide an error message to the user who is attempting this combination. I am leaving this as its own change, separate from the one that implements '--bundle-uri', because this is more of an advisory for the user. There is nothing wrong with bootstrapping with bundles and then fetching a shallow clone. However, that is likely going to involve too much work for the client _and_ the server. The client will download all of this bundle information containing the full history of the repository only to ignore most of it. The server will get a shallow fetch request, but with a list of haves that might cause a more painful computation of that shallow pack-file. RFC-TODO: add a test case for this error message. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
It will likely be rare where a user uses a single bundle URI and expects that URI to point to a bundle. Instead, that URI will likely be a list of bundles provided in some format. Alternatively, the Git server could advertise a list of bundles. In anticipation of these two ways of advertising multiple bundles, create a data structure that represents such a list. This will be populated using a common API, but for now focus on what data can be represented. Each list contains a number of remote_bundle_info structs. These contain an 'id' that is used to uniquely identify them in the list, and also a 'uri' that contains the location of its data. Finally, there is a strbuf containing the filename used when Git downloads the contents to disk. The list itself stores these remote_bundle_info structs in a hashtable using 'id' as the key. The order of the structs in the input is considered unimportant, but future modifications to the format and these data structures will place ordering possibilities on the set. The list also has a few "global" properties, including the version (used when parsing the list) and the mode. The mode is one of these two options: 1. BUNDLE_MODE_ALL: all listed URIs are intended to be combined together. The client should download all of the advertised data to have a complete copy of the data. 2. BUNDLE_MODE_ANY: any one listed item is sufficient to have a complete copy of the data. The client can choose arbitrarily from these options. In the future, the client may use pings to find the closest URI among geodistributed replicas, or use some other heuristic information added to the format. This API is currently unused, but will soon be expanded with parsing logic and then be consumed by the bundle URI download logic. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
There will be two primary ways to advertise a bundle list: as a list of packet lines in Git's protocol v2 and as a config file served from a bundle URI. Both of these fundamentally use a list of key-value pairs. We will use the same set of key-value pairs across these formats. Create a new bundle_list_update() method that is currently unusued, but will be used in the next change. It inspects each key to see if it is understood and then applies it to the given bundle_list. Here are the keys that we teach Git to understand: * bundle.list.version: This value should be an integer. Git currently understands only version 1 and will ignore the list if the version is any other value. This version can be increased in the future if we need to add new keys that Git should not ignore. We can add new "heuristic" keys without incrementing the version. * bundle.list.mode: This value should be one of "all" or "any". If this mode is not understood, then Git will ignore the list. This mode indicates whether Git needs all of the bundle list items to make a complete view of the content or if any single item is sufficient. The rest of the keys use a bundle identifier "<id>" as part of the key name, and this cannot equal "list". Keys using the same "<id>" describe a common bundle list item. * bundle.<id>.uri: This stores the URI of the bundle item. This currently is expected to be an absolute URI, but will be relaxed to be a relative URI in the future. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
When advertising a bundle list over Git's protocol v2, we will use packet lines. Each line will be of the form "key=value" representing a bundle list. Connect the API necessary for Git's transport to the key-value pair parsing created in the previous change. Co-authored-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Create a new 'test-tool bundle-uri' test helper. This helper will assist in testing logic deep in the bundle URI feature. This change introduces the 'parse-key-values' subcommand, which parses stdin as a list of lines. These are fed into bundle_uri_parse_line() to test how we construct a 'struct bundle_list' from that data. The list is then output to stdout as if the key-value pairs were a Git config file. Co-authored-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com>
The next change will start allowing us to parse bundle lists that are downloaded from a provided bundle URI. Those lists might point to other lists, which could proceed to an arbitrary depth (and even create cycles). Restructure fetch_bundle_uri() to have an internal version that has a recursion depth. Compare that to a new max_bundle_uri_depth constant that is twice as high as we expect this depth to be for any legitimate use of bundle list linking. We can consider making max_bundle_uri_depth a configurable value if there is demonstrated value in the future. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
When a bundle provider wants to operate independently from a Git remote, they want to provide a single, consistent URI that users can use in their 'git clone --bundle-uri' commands. At this point, the Git client expects that URI to be a single bundle that can be unbundled and used to bootstrap the rest of the clone from the Git server. This single bundle cannot be re-used to assist with future incremental fetches. To allow for the incremental fetch case, teach Git to understand a bundle list that could be advertised at an independent bundle URI. Such a bundle list is likely to be inspected by human readers, even if only by the bundle provider creating the list. For this reason, we can take our expected "key=value" pairs and instead format them using Git config format. Create parse_bundle_list_in_config_format() to parse a file in config format and convert that into a 'struct bundle_list' filled with its understanding of the contents. Be careful to call git_config_from_file_with_options() because the default action for git_config_from_file() is to die() on a parsing error. The current warning isn't particularly helpful if it arises to a user, but it will be made more verbose at a higher layer later. Update 'test-tool bundle-uri' to take this config file format as input. It uses a filename instead of stdin because there is no existing way to parse a FILE pointer in the config machinery. Using git_config_from_mem() is overly complicated and more likely to introduce bugs than this simpler version. I would rather have a slightly confusing test helper than complicated product code. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
When the content at a given bundle URI is not understood as a bundle (based on inspecting the initial content), then Git currently gives up and ignores that content. Independent bundle providers may want to split up the bundle content into multiple bundles, but still make them available from a single URI. Teach Git to attempt parsing the bundle URI content as a Git config file providing the key=value pairs for a bundle list. Git then looks at the mode of the list to see if ANY single bundle is sufficient or if ALL bundles are required. The content at the selected URIs are downloaded and the content is inspected again, creating a recursive process. To guard the recursion against malformed or malicious content, limit the recursion depth to a reasonable four for now. This can be converted to a configured value in the future if necessary. The value of four is twice as high as expected to be useful (a bundle list is unlikely to point to more bundle lists). RFC TODO: add tests for this feature right now. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Add a skeleton server-side implementation of a new "bundle-uri" command to protocol v2. This will allow conforming clients to optionally seed their initial clones or incremental fetches from URLs containing "*.bundle" files created with "git bundle create". This change only performs the basic boilerplate of advertising a new protocol v2 capability. The new 'bundle-uri' capability allows a client to request a list of bundles. Right now, the server only returns a flush packet, which corresponds to an empty advertisement. The critical bit right now is that the new boolean uploadPack.adverstiseBundleURIs config value signals whether or not this capability should be advertised at all. RFC TODO: Write documentation. RFC TODO: Compare to original implementation. Co-authored-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Set up all the needed client parts of the "bundle-uri" protocol
extension, without actually doing anything with the bundle URIs.
I.e. if the server says it supports "bundle-uri" we'll issue a
command=bundle-uri after command=ls-refs when we're cloning. We'll
parse the returned output using the code already tested for in
t5750-bundle-uri-parse.sh.
What we aren't doing is actually acting on that data, i.e. downloading
the bundle(s) before we get to doing the command=fetch, and adjusting
our negotiation dialog appropriately. I'll do that in subsequent
commits.
There's a question of what level of encapsulation we should use here,
I've opted to use connect.h in clone.c, but we could also e.g. make
transport_get_remote_refs() invoke this, i.e. make it implicitly get
the bundle-uri list for later steps.
This approach means that we don't "support" this in "git fetch" for
now. I'm starting with the case of initial clones, although as noted
in preceding commits to the protocol documentation nothing about this
approach precludes getting bundles on incremental fetches.
For the t5732-protocol-v2-bundle-uri-http.sh it's not easy to set
environment variables for git-upload-pack (it's started by Apache), so
let's skip the test under T5730_HTTP, and add unused T5730_{FILE,GIT}
prerequisites for consistency and future use.
Co-authored-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
TODO: make this a test-helper instead of its own builtin? Add a git-ls-remote-bundle-uri command, this is a thin wrapper for issuing protocol v2 "bundle-uri" commands to a server, and to the parsing routines in bundle-uri.c. Since in the "git clone" case we'll have already done the handshake(), but not here, introduce a "got_advertisement" state along with "got_remote_heads". It seems to me that the "got_remote_heads" is badly named in the first place, and the whole logic of eagerly getting ls-refs on handshake() or not could be refactored somewhat, but let's not do that now, and instead just add another self-documenting state variable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com>
TODO: fill in details Signed-off-by: Derrick Stolee <derrickstolee@github.com>
The yet-to-be introduced client support for bundle-uri will always fall back on a full clone, but we'd still like to be able to ignore a server's bundle-uri advertisement entirely. The new transfer.bundleURI config option defaults to 'false', but a user can set it to 'true' to enable checking for bundle URIs from the origin Git server using protocol v2. To enable this setting by default in the correct tests, add a GIT_TEST_BUNDLE_URI environment variable. Co-authored-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Bundle providers may want to distribute that data across multiple CDNs. This might require a change in the base URI, all the way to the domain name. If all bundles require an absolute URI in their 'uri' value, then every push to a CDN would require altering the table of contents to match the expected domain and exact location within it. Allow a bundle list to specify a relative URI for the bundles. This allows easier distribution of bundle data. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
The logic in fetch_bundle_uri() is useful for the --bundle-uri option of 'git clone', but is not helpful when the clone operation discovers a list of URIs from the bundle-uri protocol v2 verb. To actually download and unbundle the advertised bundles, we need a different mechanism. Create the new fetch_bundle_list() method which is very similar to fetch_bundle_uri() except that it relies on download_bundle_list() instead of fetch_bundle_uri_internal(). The download_bundle_list() method will recursively call fetch_bundle_uri_internal() if any of the advertised URIs serve a bundle list instead of a bundle. This will also follow the bundle.list.mode setting from the input list: "any" will download only one such URI while "all" will download data from all of the URIs. In an identical way to the fetch_bundle_uri(), the bundles are unbundled after all of the bundle lists have been expanded and all necessary URIs. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
A previous change introduced the transport methods to acquire a bundle list from the 'bundle-uri' protocol v2 verb, when advertised _and_ when the client has chosen to enable the feature. Teach Git to download and unbundle the data advertised by those bundles during 'git clone'. Also, since the --bundle-uri option exists, we do not want to mix the advertised bundles with the user-specified bundles. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
This test demonstrates an end-to-end form of the bundle URI feature given by an HTTP server advertising the 'features' capability with a bundle URI that is a bundle file on that same HTTP server. We verify that we unbundled a bundle, which could only have happened if we successfully downloaded that file. RFC-TODO: Create similar tests throughout the series that perform similar tests, including examples with table of contents and partial clones. Signed-off-by: Derrick Stolee <derrickstolee@github.com>
derrickstolee
force-pushed
the
bundle-redo/rfc-3
branch
from
e07e1c5
to
de1a0ce
Compare
|
/submit |
|
Submitted as pull.1234.git.1653072042.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
This branch is now known as |
|
This patch series was integrated into seen via git@452de2a. |
|
This patch series was integrated into seen via git@c5c19a6. |
|
There was a status update in the "Cooking" section about the branch source: <pull.1233.git.1652731865.gitgitgadget@gmail.com> source: <pull.1234.git.1653072042.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@c49b3ca. |
|
This patch series was integrated into seen via git@b24442c. |
|
This branch is now known as |
|
This patch series was integrated into seen via git@58fef5f. |
|
This patch series was integrated into seen via git@b24442c. |
|
This patch series was integrated into seen via git@9197f84. |
|
This patch series was integrated into seen via git@af4dcb7. |
|
This patch series was integrated into seen via git@de40345. |
|
This patch series was integrated into seen via git@87211a4. |
|
This patch series was integrated into seen via git@72bcaa4. |
|
This patch series was integrated into seen via git@80b1131. |
|
There was a status update in the "New Topics" section about the branch source: <pull.1234.git.1653072042.gitgitgadget@gmail.com> source: <pull.1233.git.1652731865.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@b44fdd9. |
|
This patch series was integrated into seen via git@83d3ccc. |
|
This patch series was integrated into seen via git@726bec2. |
|
There was a status update in the "Cooking" section about the branch RFC/ seems to trigger errors in linux-leaks CI job source: <pull.1234.git.1653072042.gitgitgadget@gmail.com> |
|
Closing now that work is being done in smaller parts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here is the latest RFC round of Bundle URIs. It combines most of the ideas from my previous RFC [5] and Ævar's latest RFC [7]. I'll start by talking about the differences from those two approaches before going into the full detail of the RFC (assuming no context of the previous discussion).
This series is based on ds/bundle-uri [8].
Comparison to Previous RFC Rounds
The two design documents from Ævar's latest RFC are combined into one and are moved up to the first patch.
The "table of contents" concept is renamed to a "bundle list". When serving from an HTTPS GET request, that still takes the form of a config file format, but the exact same key=value pairs are also used in the
bundle-uriprotocol v2 verb. Both use a common underlying logic for downloading from lists that are found in either way. Since I modified Ævar'sbundle-uriprotocol v2 logic to match this common model, I was able to preserve his authorship on several patches, but some were different enough that I added my co-authorship.The bundle list has a new
bundle.list.modesetting that can beall(get everything) orany(get one). This allows thebundle-uriverb to advertise multiple bundle servers where any one of them would be sufficient to get a recent view of the repository.The timestamp heuristic is removed from this series for the sake of brevity. The logic for downloading the bundles can be modified in the future to take advantage of such a heuristic if it is added in the future.
Ævar's use of shelling out to
curlis completely removed. This was causing test failures on Windows but also has no way of integrating with the credential manager at the moment, which is critical to serving private repository data via bundles. Similar to the timestamp heuristic, this "fetch the headers first" heuristic can be added later.Because these heuristics are removed, the incremental bundle fetches during
git fetchare also removed. This needs at least one heuristic, so is an intended target after thegit cloneintegration is more stable.Instead of creating
git bundle fetch, I implemented the same functionality intogit fetch --bundle-uri=X, which is perhaps more understandable to users. This command will allow users to fetch from bundles on their own timeline if they don't want to rely on Git auto-discovering or auto-fetching from bundles.Both the
git clone --bundle-uriand the discovery from thebundle-uriprotocol v2 system are provided.The
transport.injectBundleURIconfig option is removed. Instead, the--bundle-uricommand-line option is provided.Ævar's series had some use of logic to feed the bundle ref advertisement directly into the fetch negotiation. This is removed in favor of storing the bundled refs in
refs/bundles/(along withlog.excludeDecoration=refs/bundles/) to automatically gain that benefit, including when using--bundle-uri.I kept and extended the tests that Ævar provided. There is a new test in the end-to-end test that includes the server advertising multiple bundles. The series as a whole is still light on tests, but I wanted to continue to focus on the viability of the design before committing too much on tests. I've marked commit messages with RFC-TODO comments which will be resolved before sending any patches for full review.
Context-Free Description
There have been several suggestions to improve Git clone speeds and reliability by supplementing the Git protocol with static content. The Packfile URI [0] feature lets the Git response include URIs that point to packfiles that the client must download to complete the request.
Last year, Ævar suggested using bundles instead of packfiles [1] [2]. This design has the same benefits to the packfile URI feature because it offloads most object downloads to static content fetches. The main advantage over packfile URIs is that the remote Git server does not need to know what is in those bundles. The Git client tells the server what it downloaded during the fetch negotiation afterwards. This includes any chance that the client did not have access to those bundles or otherwise failed to access them. I agreed that this was a much more desirable way to serve static content but had concerns about the flexibility of that design [3]. I started investigating this idea myself in December, resulting in an RFC in February [5]. After some discussion, we agreed [6] that Ævar would combine my ideas with his, including the patches that had not been shared publicly. Ævar's latest RFC [7] includes the two implementations mostly side-by-side, with some early refactoring patches that help both implementations. I submitted those early patches for full review [8], now known as ds/bundle-uri.
Notable to this topic, although not used directly in this RFC, is the notion of partial bundles [4] which landed as a feature in Git 2.36.0. This allows us to create bundles that respect a partial clone filter. While this RFC does not implement the awareness of filters when downloading bundles, it would be relatively simple to modify the implementation to include those checks. My previous RFC [5] had that integration, for reference.
The first patch of this series is a design document detailing how the bundle URI feature works in its ideal, feature-complete state (along with ways it can be extended with more features in the future). I focused on maximizing flexibility for the service that organizes and serves bundles. This includes:
Git servers can advertise bundle URIs using the Git protocol.
Users can set up bundle servers independent of the remote Git server if they specify the bundle URI via a
--bundle-uriargument.Bundle URIs work for full and partial clones.
Bundle URIs can assist with
git fetchin addition togit clone.The general breakdown is as follows:
Patch 1 adds documentation for the feature in its entirety.
Patches 2-8 add the
git fetch --bundle-uri=<X>andgit clone --bundle-uri=<X>functionality for a single bundle (no bunde lists).Patches 9-15 add the bundle list data structures and basic parsing so that
git clone --bundle-uri=<X>can download bundles based on a bundle list.Patches 16-24 add the
bundle-uriprotocol v2 verb and allowsgit cloneto discover and download a bundle list advertised by the server.I consider the patches in their current form to be “RFC quality”. There are multiple places where tests are missing or special cases are not checked. The goal for this RFC is to seek feedback on the high-level ideas before committing to the deep work of creating mergeable patches.
My previous RFC [5] included a running server prototype using static HTTPS content that is generated by a daily job. I updated that prototype to use the new bundle list format, but since this RFC does not include understanding the timestamp heuristic or the partial clone filters, the RFC isn't appropriate for performance testing with that data. The clones will still work, but they will download extra data (both the full and partial bundles).
Intended Focus of this RFC
This RFC is very large, and that's even with many patches not including full documentation or tests. These commits are not intended to be reviewed as if I intended to merge this as-is.
One thing this feature establishes is a new standard by which the Git client will communicate with external servers. The goal of this RFC is to determine if this standard is well designed, and whether we need to make it more robust. Alternatively, the design might need to be changed for reasons I cannot predict.
[0] https://github.com/git/git/blob/master/Documentation/technical/packfile-uri.txt
The packfile URI feature in Git (Created June 2020)
[1] https://lore.kernel.org/git/RFC-cover-00.13-0000000000-20210805T150534Z-avarab@gmail.com/
An earlier RFC for a bundle URI feature. (August 2021)
[2] https://lore.kernel.org/git/cover-0.3-00000000000-20211025T211159Z-avarab@gmail.com/
An earlier patch series creating a 'bundle-uri' protocol v2 capability. (October 2021)
[3] https://lore.kernel.org/git/e7fe220b-2877-107e-8f7e-ea507a65feff@gmail.com/
My earlier thoughts on the previous RFCs, many of which are integrated into this RFC (August 2021)
[4] https://lore.kernel.org/git/pull.1159.git.1645638911.gitgitgadget@gmail.com/
Add object filters to bundles (February 2022)
[5] https://lore.kernel.org/git/pull.1160.git.1645641063.gitgitgadget@gmail.com
[RFC] Bundle URIs (February 2022)
[6] https://lore.kernel.org/git/ddebc223-1e13-e758-f9b1-d3f23961e459@github.com/
Summary of my conversation with Ævar (March 2022)
[7] https://lore.kernel.org/git/RFC-cover-v2-00.36-00000000000-20220418T165545Z-avarab@gmail.com/
[RFC PATCH v2 00/36] bundle-uri: a "dumb CDN" for git + TOC format (April 2022)
[8] https://lore.kernel.org/git/pull.1233.git.1652731865.gitgitgadget@gmail.com/
[PATCH 0/8] Bundle URIs: Prepatory patches (May 2022)
Thanks,
-Stolee
cc: gitster@pobox.com
cc: me@ttaylorr.com
cc: newren@gmail.com
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com
cc: Teng Long dyroneteng@gmail.com
cc: Johannes Schindelin Johannes.Schindelin@gmx.de