| Message ID | 01ab2cbb34e6eb5f9b421d34ac368ea4e266fcd1.1627292425.git.dyroneteng@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | packfile-uris: commit objects exclusio | expand |
Teng Long <dyroneteng@gmail.com> writes: > +++ b/Documentation/technical/packfile-uri.txt > @@ -35,13 +35,16 @@ include some sort of non-trivial implementation in the Minimum Viable Product, > at least so that we can test the client. > > This is the implementation: a feature, marked experimental, that allows the > +server to be configured by one or more entries with the format: > + > + uploadpack.excludeobject=<object-hash> <recursively> <pack-hash> <uri> > + > +Value <object-hash> is the key of entry, and the object type can be a blob > +or commit. Whenever the list of objects to be sent is assembled, all such > +objects are excluded, replaced with URIs. At the same time, for the old > +configuration `uploadpack.blobPackfileUri=<sha1> <pack-hash> <uri>` is > +still compatible for now, but this configuration only supports the > +exclusion of blob objects. Do not hint deprecation and future removal with "still" and "for now", before seeing a concensus that it should be deprecated and removed. The new thing, <recursively>, deserves some explanation. What are the acceptable values (yes/no? spatial/time/both? infinitely/limited?) and what do these values mean? Why is this limited to only <blob> and <commit>? There isn't a fundamental reason why I shouldn't be able to say "v2.32.0" instead of ebf3c04b262aa27fbb97f8a0156c2347fecafafb (or "v2.32.0~0") to say "I want anything reachable from v2.32.0 (in other words, that version and everything before it)", is there? For that matter, "everything reachable from this tree object" may also be a reasonable way to specify which set of objects are offloaded to an out-of-band URI. Thanks.
>>Do not hint deprecation and future removal with "still" and "for >>now", before seeing a concensus that it should be deprecated and >>removed. Agree. Will remove. >>The new thing, <recursively>, deserves some explanation. What are >>the acceptable values (yes/no? spatial/time/both? infinitely/limited?) >>and what do these values mean? More expanation. I think over about <recursively> and consider to remove it in next patch because offer a pack only contains commit or tree object individually may not make much sense, so <recursively> will remove(as default on tree and commit object) in next patch. >>Why is this limited to only <blob> and <commit>? Will support tree but not tag(maybe furture work) in next patch. >>There isn't a fundamental reason why I shouldn't be able to say >>"v2.32.0" instead of ebf3c04b262aa27fbb97f8a0156c2347fecafafb (or >>"v2.32.0~0") to say "I want anything reachable from v2.32.0 (in >>other words, that version and everything before it)", is there? >>For that matter, "everything reachable from this tree object" may >>also be a reasonable way to specify which set of objects are >>offloaded to an out-of-band URI. Agree. Will provide more detailed instuctions in next patch. Thank you.
diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt index f7eabc6c76..2532db0e99 100644 --- a/Documentation/technical/packfile-uri.txt +++ b/Documentation/technical/packfile-uri.txt @@ -35,13 +35,16 @@ include some sort of non-trivial implementation in the Minimum Viable Product, at least so that we can test the client. This is the implementation: a feature, marked experimental, that allows the -server to be configured by one or more `uploadpack.blobPackfileUri=<sha1> -<uri>` entries. Whenever the list of objects to be sent is assembled, all such -blobs are excluded, replaced with URIs. As noted in "Future work" below, the -server can evolve in the future to support excluding other objects (or other -implementations of servers could be made that support excluding other objects) -without needing a protocol change, so clients should not expect that packfiles -downloaded in this way only contain single blobs. +server to be configured by one or more entries with the format: + + uploadpack.excludeobject=<object-hash> <recursively> <pack-hash> <uri> + +Value <object-hash> is the key of entry, and the object type can be a blob +or commit. Whenever the list of objects to be sent is assembled, all such +objects are excluded, replaced with URIs. At the same time, for the old +configuration `uploadpack.blobPackfileUri=<sha1> <pack-hash> <uri>` is +still compatible for now, but this configuration only supports the +exclusion of blob objects. Client design ------------- @@ -65,9 +68,6 @@ The protocol design allows some evolution of the server and client without any need for protocol changes, so only a small-scoped design is included here to form the MVP. For example, the following can be done: - * On the server, more sophisticated means of excluding objects (e.g. by - specifying a commit to represent that commit and all objects that it - references). * On the client, resumption of clone. If a clone is interrupted, information could be recorded in the repository's config and a "clone-resume" command can resume the clone in progress. (Resumption of subsequent fetches is more
Signed-off-by: Teng Long <dyroneteng@gmail.com> --- Documentation/technical/packfile-uri.txt | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)