{"thread":{"id":"50999","subject":"add 'ls-remote' option to limit output records","startedAt":"2019-04-26T18:57:01Z","lastAt":"2019-05-01T18:23:29Z","messageCount":3,"participants":["David Carson","Bryan Turner","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"374568","messageId":"560CCADB-511B-495E-B86B-F294486C088C@contoso.com","threadId":"50999","inReplyTo":null,"subject":"add 'ls-remote' option to limit output records","fromName":"David Carson","fromEmail":"dcarson@extremenetworks.com","sentAt":"2019-04-26T18:56:55Z","receivedAt":"2019-04-26T18:57:01Z","isPatch":false,"sender":{"key":"dcarson@extremenetworks.com","avatar":null},"body":"Given that 'ls-remote' can be sorted, it would be useful to be able to ask for a subset of the total number of result records.\n\nFor example, if I want to retrieve only the tag with the highest version, I would do so by adding this new option (-n1 in my example):\n\n\t$ git ls-remote -n1 --tags --sort=v:refname origin \"v*\"\n\nThat would save from having to receive a large list of tags from the remote, only one of which I care about.\n\n~David\n\n\n"},{"id":"374573","messageId":"CAGyf7-G+FEDVe=WiVVNJr1ALn-ryA4862qbjdDCNXM+LhpjORQ@mail.gmail.com","threadId":"50999","inReplyTo":"560CCADB-511B-495E-B86B-F294486C088C@contoso.com","subject":"Re: add 'ls-remote' option to limit output records","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2019-04-26T19:32:51Z","receivedAt":"2019-04-26T19:33:07Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Fri, Apr 26, 2019 at 11:57 AM David Carson\n<DCarson@extremenetworks.com> wrote:\n>\n> Given that 'ls-remote' can be sorted, it would be useful to be able to ask for a subset of the total number of result records.\n>\n> For example, if I want to retrieve only the tag with the highest version, I would do so by adding this new option (-n1 in my example):\n>\n>         $ git ls-remote -n1 --tags --sort=v:refname origin \"v*\"\n>\n> That would save from having to receive a large list of tags from the remote, only one of which I care about.\n\nThat sort of filtering would have to be applied client side, at least\npartially, so it wouldn't necessarily save as much as you'd hope.\n\nWith the v0/v1 wire protocol, the server speaks first and sends the\nentire ref advertisement, so the filtering would have to be 100%\nclient side.\n\nWith the v2 wire protocol, the client could provide a prefix (like\n`refs/tags/`, or potentially `refs/tags/v`) to reduce what the server\nincluded in the ref advertisement, but even the v2 protocol doesn't\nhave anything for telling the server \"Version parse these names and\nthen return the first N\". That means the parsing, sorting and trimming\nfor the advertised tags would still all have to happen locally. (I'm\nsure someone can correct me if I've misstated what protocol v2 can do\nfor filtering, but I don't see any \"ls-refs\" options that look like\nthey enable anything other than prefix matching.)\n\nNot trying to imply any judgments on the feature request itself; I'm\njust noting that if it was added it may not be quite the win you were\nhoping for. In fact, with the existing wire protocol versions (all of\nthem), I suspect this would end up with identical bandwidth usage to:\n\n$ git ls-remote --tags --sort=v:refname origin \"v*\" | head -1\n\nIt would take modifications to the wire protocol itself for this to\nhappen server-side, not just the `ls-remote` command.\n\nBryan\n"},{"id":"374773","messageId":"20190501182323.GD4109@sigill.intra.peff.net","threadId":"50999","inReplyTo":"CAGyf7-G+FEDVe=WiVVNJr1ALn-ryA4862qbjdDCNXM+LhpjORQ@mail.gmail.com","subject":"Re: add 'ls-remote' option to limit output records","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-05-01T18:23:23Z","receivedAt":"2019-05-01T18:23:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 26, 2019 at 12:32:51PM -0700, Bryan Turner wrote:\n\n> >         $ git ls-remote -n1 --tags --sort=v:refname origin \"v*\"\n> [...]\n> With the v2 wire protocol, the client could provide a prefix (like\n> `refs/tags/`, or potentially `refs/tags/v`) to reduce what the server\n> included in the ref advertisement, but even the v2 protocol doesn't\n> have anything for telling the server \"Version parse these names and\n> then return the first N\". That means the parsing, sorting and trimming\n> for the advertised tags would still all have to happen locally. (I'm\n> sure someone can correct me if I've misstated what protocol v2 can do\n> for filtering, but I don't see any \"ls-refs\" options that look like\n> they enable anything other than prefix matching.)\n\nNo, that sounds right. The \"--tags\" in the original command should cause\nv2 to ask only for refs/tags/. But because of the way ls-remote matching\nworks, \"v*\" is not a pure prefix match, and would find\n\"refs/tags/foo/v1.2.3\". So we can't use protocol-level matching to ask\nfor \"refs/tags/v*\".\n\nThere are no provisions in the protocol for sorting, nor for limiting\nthe output.\n\nI didn't check, but I suspect some hosting-platform APIs might be able\nto answer this with a single query.\n\n-Peff\n"}]}