On Sat, Mar 7, 2015 at 11:28 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >>> +---- >>> + advertised-refs = (no-refs / list-of-refs) >>> + *shallow >>> + flush-pkt >> >> I am not sure if defining "shallow" as part of "refs advertisement" >> is a good idea. The latter lives in the same place in the v1 >> protocol merely because that was how it was later bolted onto the >> protocol. But this concern can easily be allayed by retitling >> "advertised-refs" to something else. > > I don't quite understand this. What are your concerns about shallow here? This made me look for explanation about these shallow lines (commit ad49136).They are sent when source repo is a shallow one. They tell the receiver about the bottom the source repo. My experiment with "git clone --since" shows that such a shallow clone could end up with a few thousand shallow lines. Not as many as refs, but sending shallow lines this way still cost more than necessary. If we want to do that, we need more flexibility that just sending all shallow lines this way. One of the approach is, because these shallow lines (on source repo) rarely change. We could simply exchange SHA-1 of the source repo's "shallow" file first. The client only requests shallow info when SHA-1 does not match. -- Duy -- 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