Nguyễn Thái Ngọc Duy  <pclo...@gmail.com> writes:

> It's introduced in 1bd8c8f (git-upload-pack: Support the multi_ack
> protocol - 2005-10-28) but probably better documented in the commit
> message of 78affc4 (Add multi_ack_detailed capability to
> fetch-pack/upload-pack - 2009-10-30)
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
> ---
>  Documentation/technical/pack-protocol.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/technical/pack-protocol.txt 
> b/Documentation/technical/pack-protocol.txt
> index c73b62f..eb0b8a1 100644
> --- a/Documentation/technical/pack-protocol.txt
> +++ b/Documentation/technical/pack-protocol.txt
> @@ -338,7 +338,8 @@ during a prior round.  This helps to ensure that at least 
> one common
>  ancestor is found before we give up entirely.
>  
>  Once the 'done' line is read from the client, the server will either
> -send a final 'ACK obj-id' or it will send a 'NAK'. The server only sends
> +send a final 'ACK obj-id' or it will send a 'NAK'. 'obj-id' is the
> +last SHA-1 determined to be common. The server only sends

I'd suggest rewording it to:

    'obj-is' is the object name of the last commit determined to be common

I do not mind too much if it used colloquial "SHA-1" in place of
"object name", but what is common is not the name but the object the
name refers to, so "the last commit" part is a moderately strong
suggestion.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to