Re: [PATCH v2] packfile-uri.txt: fix blobPackfileUri description

Teng Long [off-list ref] writes:

Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt
and the correct format also can be seen in t5702.

Jonathan Tan [off-list ref] writes:

quoted

As for the commit message, limit the title to 50 characters or fewer if
possible. Maybe something like "packfile-uri.txt: fix blobPackfileUri
description" or something like that.

Thanks for mention this, "packfile-uri.txt: fix blobPackfileUri
description" is good and meets the "50 characters" requirement. So the
title is modified. 

quoted

Also in the commit message, maybe mention that the correct format can be
seen in t5702.

Because I am implementing another patch[1] about supporting the commit
object in packfile-uri, I noticed the `configure_exclusion` function in
t5702, which is now mentioned in the commit message.

[1]https://public-inbox.org/git/20210507021140.31372-1-dyroneteng@gmail.com

Signed-off-by: Teng Long <redacted>
---

It seems that the above needs a bit more polishing?

I am not sure if moving the sign-off higher and inserting a
three-dash line before "Jonathan Tan writes" would be sufficient,
but with everything under that quoted material does not seem to
belong to a proposed commit log message proper.

Thanks.

It seems that the above needs a bit more polishing?

I am not sure if moving the sign-off higher and inserting a
three-dash line before "Jonathan Tan writes" would be sufficient,
but with everything under that quoted material does not seem to
belong to a proposed commit log message proper.

Sorry, I misunderstood.

I looked at some patches in the community. If I reply to the
reviewer’s suggestion separately and then submit a new patch, is it
the recommended way? (Distinguish between the ‘reply‘ and the
'patch').

Another question is, if I need to continue to complete this patch,
what do I need to do? I think it is to reply to Jonathan Tan
separately, and then resubmit Patch v2. Is this way correct?

Thanks for your reply.

Junio C Hamano [off-list ref] 于2021年5月12日周三 上午4:50写道：

Teng Long [off-list ref] writes:

quoted

Fix the 'uploadpack.blobPackfileUri' description in packfile-uri.txt
and the correct format also can be seen in t5702.

Jonathan Tan [off-list ref] writes:

quoted

As for the commit message, limit the title to 50 characters or fewer if
possible. Maybe something like "packfile-uri.txt: fix blobPackfileUri
description" or something like that.

Thanks for mention this, "packfile-uri.txt: fix blobPackfileUri
description" is good and meets the "50 characters" requirement. So the
title is modified.

quoted

Also in the commit message, maybe mention that the correct format can be
seen in t5702.

Because I am implementing another patch[1] about supporting the commit
object in packfile-uri, I noticed the `configure_exclusion` function in
t5702, which is now mentioned in the commit message.

[1]https://public-inbox.org/git/20210507021140.31372-1-dyroneteng@gmail.com

Signed-off-by: Teng Long <redacted>
---

It seems that the above needs a bit more polishing?

I am not sure if moving the sign-off higher and inserting a
three-dash line before "Jonathan Tan writes" would be sufficient,
but with everything under that quoted material does not seem to
belong to a proposed commit log message proper.

Thanks.

quoted

 Documentation/technical/packfile-uri.txt | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

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
 -------------