From: David Lang <david@lang.hm>
Date: Mon, 02 Mar 2015 01:09:12 GMT
Subject: Re: [RFC/PATCH 0/3] protocol v2
Message-ID: <alpine.DEB.2.02.1503011707040.12474@nftneq.ynat.uz>
In-Reply-To: <xmqqwq30fhbg.fsf@gitster.dls.corp.google.com>

On Sun, 1 Mar 2015, Junio C Hamano wrote:

> and if the only time your refs/remotes/origin/* hierarchy changes is
> when you fetch from there (which should be the norm), you can look
> into remote.origin.fetch refspec (to learn that "refs/heads*" is
> what you are asking) and your refs/remotes/origin/* refs (and
> reverse the mapping you make when you fetch to make them talk about
> refs/heads/* hierarchy on the server side), you can compute it
> locally.
>
> The latter will have one benefit over "opaque thing the client does
> not know how to compute".  Because I want us avoid sending unchanged
> refs over connection, but I do want to see the protocol has some
> validation mechanism built in, even if we go the latter "client can
> compute what the state name ought to be" route, I want the servrer
> to tell the client what to call that state.  That way, the client
> side can tell when it goes out of sync for any reason and attempt to
> recover.

how would these approaches be affected by a client that is pulling from 
different remotes into one local repository? For example, pulling from the main 
kernel repo and from the -stable repo.

David Lang