| Message ID | 20210513071547.64367-1-dyroneteng@gmail.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 3127ff90ea359c5be0d61c2885b3f0f74d602faf |
| Headers | show |
| Series | packfile-uri.txt: fix blobPackfileUri description | expand |
Teng Long <dyroneteng@gmail.com> writes: > Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt > and the correct format also can be seen in t5702. > > Signed-off-by: Teng Long <dyroneteng@gmail.com> > --- > Documentation/technical/packfile-uri.txt | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) Will queue; thanks. Jonathan, how does this look? > diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt > index f7eabc6c76..1eb525fe76 100644 > --- a/Documentation/technical/packfile-uri.txt > +++ b/Documentation/technical/packfile-uri.txt > @@ -35,13 +35,14 @@ 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 `uploadpack.blobPackfileUri= > +<object-hash> <pack-hash> <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. > > Client design > -------------
Junio C Hamano <gitster@pobox.com> writes: > Teng Long <dyroneteng@gmail.com> writes: > >> Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt >> and the correct format also can be seen in t5702. >> >> Signed-off-by: Teng Long <dyroneteng@gmail.com> >> --- >> Documentation/technical/packfile-uri.txt | 15 ++++++++------- >> 1 file changed, 8 insertions(+), 7 deletions(-) > > Will queue; thanks. > > Jonathan, how does this look? Ping? >> diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt >> index f7eabc6c76..1eb525fe76 100644 >> --- a/Documentation/technical/packfile-uri.txt >> +++ b/Documentation/technical/packfile-uri.txt >> @@ -35,13 +35,14 @@ 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 `uploadpack.blobPackfileUri= >> +<object-hash> <pack-hash> <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. >> >> Client design >> -------------
> Junio C Hamano <gitster@pobox.com> writes: > > > Teng Long <dyroneteng@gmail.com> writes: > > > >> Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt > >> and the correct format also can be seen in t5702. > >> > >> Signed-off-by: Teng Long <dyroneteng@gmail.com> > >> --- > >> Documentation/technical/packfile-uri.txt | 15 ++++++++------- > >> 1 file changed, 8 insertions(+), 7 deletions(-) > > > > Will queue; thanks. > > > > Jonathan, how does this look? > > Ping? Sorry, I just got back on vacation. This looks good - it's exactly the same as the change I approved previously [1]. Teng Long, for future reviews, the review would go faster if you mentioned the changes in between versions (e.g. in this case, you updated the commit message following my suggestions). [1] https://lore.kernel.org/git/20210506164728.336409-1-jonathantanmy@google.com/
Jonathan Tan <jonathantanmy@google.com> writes: >> Junio C Hamano <gitster@pobox.com> writes: >> >> > Teng Long <dyroneteng@gmail.com> writes: >> > >> >> Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt >> >> and the correct format also can be seen in t5702. >> >> >> >> Signed-off-by: Teng Long <dyroneteng@gmail.com> >> >> --- >> >> Documentation/technical/packfile-uri.txt | 15 ++++++++------- >> >> 1 file changed, 8 insertions(+), 7 deletions(-) >> > >> > Will queue; thanks. >> > >> > Jonathan, how does this look? >> >> Ping? > > Sorry, I just got back on vacation. This looks good - it's exactly the > same as the change I approved previously [1]. Thanks. > > Teng Long, for future reviews, the review would go faster if you > mentioned the changes in between versions (e.g. in this case, you > updated the commit message following my suggestions). > > [1] https://lore.kernel.org/git/20210506164728.336409-1-jonathantanmy@google.com/
diff --git a/Documentation/technical/packfile-uri.txt b/Documentation/technical/packfile-uri.txt index f7eabc6c76..1eb525fe76 100644 --- a/Documentation/technical/packfile-uri.txt +++ b/Documentation/technical/packfile-uri.txt @@ -35,13 +35,14 @@ 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 `uploadpack.blobPackfileUri= +<object-hash> <pack-hash> <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. Client design -------------
Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt and the correct format also can be seen in t5702. Signed-off-by: Teng Long <dyroneteng@gmail.com> --- Documentation/technical/packfile-uri.txt | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)