git/Documentation/technical, branch v2.10.2

Merge branch 'ls/packet-line-protocol-doc-fix'

2016-08-31T17:03:51Z

Correct an age-old calco (is that a typo-like word for calc) in the documentation. * ls/packet-line-protocol-doc-fix: pack-protocol: fix maximum pkt-line size

pack-protocol: fix maximum pkt-line size

2016-08-30T18:00:29Z

According to LARGE_PACKET_MAX in pkt-line.h the maximal length of a pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and therefore the pkt-line data component must not exceed 65516 bytes. Signed-off-by: Lars Schneider Signed-off-by: Junio C Hamano

Merge branch 'jc/hashmap-doc-init'

2016-08-08T21:48:45Z

The API documentation for hashmap was unclear if hashmap_entry can be safely discarded without any other consideration. State that it is safe to do so. * jc/hashmap-doc-init: hashmap: clarify that hashmap_entry can safely be discarded

Merge branch 'sb/pack-protocol-doc-nak'

2016-08-04T21:39:16Z

A doc update. * sb/pack-protocol-doc-nak: Documentation: pack-protocol correct NAK response

hashmap: clarify that hashmap_entry can safely be discarded

2016-08-02T21:34:17Z

The API documentation said that the hashmap_entry structure to be embedded in the caller's structure is to be treated as opaque, which left the reader wondering if it can safely be discarded when it no longer is necessary. If the hashmap_entry structure had references to external resources such as allocated memory or an open file descriptor, merely free(3)ing the containing structure (when the caller's structure is on the heap) or letting it go out of scope (when it is on the stack) would end up leaking the external resource. Document that there is no need for hashmap_entry_clear() that corresponds to hashmap_entry_init() to give the API users a little bit of peace of mind. Signed-off-by: Junio C Hamano

Documentation: pack-protocol correct NAK response

2016-07-22T20:31:55Z

In the transport protocol we use NAK to signal the non existence of a common base, so fix the documentation. This helps readers of the document, as they don't have to wonder about the difference between NAK and NACK. As NACK is used in git archive and upload-archive, this is easy to get wrong. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

receive-pack: implement advertising and receiving push options

2016-07-14T22:50:40Z

The pre/post receive hook may be interested in more information from the user. This information can be transmitted when both client and server support the "push-options" capability, which when used is a phase directly after update commands ended by a flush pkt. Similar to the atomic option, the server capability can be disabled via the `receive.advertisePushOptions` config variable. While documenting this, fix a nit in the `receive.advertiseAtomic` wording. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano

Documentation/technical: signed merge tag format

2016-06-17T19:10:48Z

Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano

Documentation/technical: signed commit format

2016-06-17T19:10:30Z

Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano

Documentation/technical: signed tag format

2016-06-17T18:40:58Z

Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano