Just realized that I haven't replied to this yet... > - I'm a little worried this may happen again with future features. The > root cause is that "ls-refs" follows a different code path than the > ref advertisement for "upload-pack". So if we add any new config, > it needs to go both places (non ref-advertisement config is OK, as > the v2 "fetch" command is a lot closer to a v0 upload-pack). > > I think this is just an issue for any future features. I looked for > other existing features which might be missing in v2, but couldn't > find any. > > I don't know if there's a good solution. I tried running the whole > test suite with v2 as the default. It does find this bug, but it has > a bunch of other problems (notably fetch-pack won't run as v2, but > some other tests I think also depend on v0's reachability rules, > which v2 is documented not to enforce). I think Aevar's patches (sent after you wrote this) is a good start, and I have started looking at it too. > - The "serve" command is funky, because it has no concept of whether > the "ls-refs" is for fetching or pushing. Is git-serve even a thing > that we want to support going forward? I know part of the original > v2 conception was that one would be able to just connect to > "git-serve" and do a number of operations. But in practice the v2 > probing requires saying "I'd like to git-upload-pack, and v2 if you > please". So no client ever calls git-serve. > > Is this something we plan to eventually move to? Or can it be > considered a funny vestige of the development? In the latter case, I > think we should consider removing it. Personally, I lean towards removing it, but there are arguments on both sides. In particular, removing "serve" means that both developers and users of Git need not be concerned with a 3rd endpoint, but preserving "serve" (and planning to migrate away from "upload-pack" and "receive-pack") means that we will only have one endpoint, eliminating confusion about which endpoint to use when making certain requests (when we add requests other than "fetch" and "push").
