On Fri, Dec 14, 2018 at 12:36:21AM -0800, Jonathan Nieder wrote: > Jeff King wrote: > > > In protocol v2, instead of just running "upload-pack", we have a generic > > "serve" loop which runs command requests from the client. What used to > > be "upload-pack" is now generally split into two operations: "ls-refs" > > and "fetch". The latter knows it must respect uploadpack.* config, but > > the former is not actually specific to a fetch operation (we do not yet > > do v2 receive-pack, but eventually we may, and ls-refs would support > > both operations). > > I think I'm missing something. Why wouldn't "ls-refs for push" not pass > the information that it's for push as part of the *body* of the ls-refs > request? I don't know. Why doesn't the current "ls-refs" say "ls-refs for fetch"? Certainly if that information was carried from the client request it would work fine, and ls-refs would have enough to know which config to respect. But I could not find any documentation on this, nor discussion of plans for a v2 push. Since that information isn't passed now, we'd have to assume that "ls-refs" without "for-push" always means "for fetch". I'm conceptually OK with that, but if that is the plan for going forward, it was not at all obvious to me (and it does feel rather implicit). > Is there some other more immediate motivation for this patch? In the > spirit of YAGNI, I would rather understand that motivation instead of > one that in many possible designs would never materialize. Without this information, in patch 3 ls-refs cannot know to look at uploadpack.hiderefs, unless it makes the implicit assumption that it is always serving a fetch. -Peff
