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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html