Am 18.09.19 um 23:44 schrieb Kamil Domański: > On 9/18/19 8:28 AM, Johannes Sixt wrote: >> Am 18.09.19 um 02:11 schrieb Kamil Domański: >>> DESCRIPTION >>> ----------- >>> @@ -21,6 +21,11 @@ commit IDs. >>> OPTIONS >>> ------- >>> +--count=<count>:: >>> + By default the command shows all refs that match >>> + `<pattern>`. This option makes it stop after showing >>> + that many refs. >> Is the meaning of this option perhaps: >> >> Stops after the specified count of refs have been listed. >> If `--sort=<key>` is specified as well, refs are counted >> after sorting; otherwise, it is unspecified which subset >> of is listed. > > Similarly, I merely copied the description used by 'for-each-ref'. I > like your version as well, since it clarifies the relation to sorting. > Should the description for 'for-each-ref' be changed as well then? I am neutral. If you do it, then it should not happen in the same patch as this change. > ... it appears that 'for-each-ref' defaults to sorting > by 'refname' (through ref_default_sorting() ) if no alternative sorting > is provided, while 'ls-remote' does no such defaulting. Do you figure it > would be a good idea to add another patch which would introduce a > similar default in 'ls-remote'? I don't think so. I would think that in the case of ls-remote it is preferable to stream refs to the output as soon as they are received from the remote. If refs must be sorted, it would have to wait until the remote has sent all refs before it can do anything. That said, Junio's question remains open: why is piping though head -n not good enough? -- Hannes
