On Fri, Feb 27, 2015 at 4:07 PM, Duy Nguyen <pclo...@gmail.com> wrote: > > There may be another hole, if we send "want <empty-tree>", it looks > like it will go through without causing errors. It's not exactly no-op > because an empty tree object will be bundled in result pack. But that > makes no difference in pratice. I didn't verify this though.
In addition to "that's not a no-op" problem, unless the old server has a ref that has an emtpy tree at its tip, such a fetch request will be rejected, unless the server is configured to serve any object, no? If your new server does have a ref that points at an empty tree, a client may request you to send that, but this is not a problem, because the new server can tell if the client is sending it as a no-op probe or a serious request by looking at its capability request. A serious old client will not tell you that he is new, a probing new client does, and a serious new client does. So your new server can tell and will not be confused. > as a commit. But even if the parsing is through, a non-empty > shallowCommits set would disable pack bitmap. Performance penalty is fine. Over time we would upgrade and the point of the exercise is not to cause the old-new or new-old pair to die but keep talking the old protocol and getting correct results. -- 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
