Re: What's cooking in git.git (Mar 2018, #05; Wed, 28)

[Brandon Williams <bmwill@google.com>]

On 03/28, Junio C Hamano wrote:
> * bw/protocol-v2 (2018-03-15) 35 commits
>  - remote-curl: don't request v2 when pushing
>  - remote-curl: implement stateless-connect command
>  - http: eliminate "# service" line when using protocol v2
>  - http: don't always add Git-Protocol header
>  - http: allow providing extra headers for http requests
>  - remote-curl: store the protocol version the server responded with
>  - remote-curl: create copy of the service name
>  - pkt-line: add packet_buf_write_len function
>  - transport-helper: introduce stateless-connect
>  - transport-helper: refactor process_connect_service
>  - transport-helper: remove name parameter
>  - connect: don't request v2 when pushing
>  - connect: refactor git_connect to only get the protocol version once
>  - fetch-pack: support shallow requests
>  - fetch-pack: perform a fetch using v2
>  - upload-pack: introduce fetch server command
>  - push: pass ref prefixes when pushing
>  - fetch: pass ref prefixes when fetching
>  - ls-remote: pass ref prefixes when requesting a remote's refs
>  - transport: convert transport_get_remote_refs to take a list of ref prefixes
>  - transport: convert get_refs_list to take a list of ref prefixes
>  - connect: request remote refs using v2
>  - ls-refs: introduce ls-refs server command
>  - serve: introduce git-serve
>  - test-pkt-line: introduce a packet-line test helper
>  - protocol: introduce enum protocol_version value protocol_v2
>  - transport: store protocol version
>  - connect: discover protocol version outside of get_remote_heads
>  - connect: convert get_remote_heads to use struct packet_reader
>  - transport: use get_refs_via_connect to get refs
>  - upload-pack: factor out processing lines
>  - upload-pack: convert to a builtin
>  - pkt-line: add delim packet support
>  - pkt-line: allow peeking a packet line without consuming it
>  - pkt-line: introduce packet_read_with_status
> 
>  The beginning of the next-gen transfer protocol.
> 
>  Is everybody happy with this version?  One design decision with
>  larger consequence "to or not to build in?" has been settled in
>  favor of status quo, IIRC.

I haven't heard anymore complaints with this version so I *think* it
should be good.

-- 
Brandon Williams