Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-27 Thread Brandon Williams
On 02/26, Jonathan Nieder wrote: > Ævar Arnfjörð Bjarmason wrote: > > On Sat, Feb 24 2018, Jeff King jotted: > > >> I actually wonder if we should just specify that the patterns must > >> _always_ be fully-qualified, but may end with a single "/*" to iterate > >> over wildcards. Or even simpler,

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-26 Thread Jonathan Nieder
Ævar Arnfjörð Bjarmason wrote: > On Sat, Feb 24 2018, Jeff King jotted: >> I actually wonder if we should just specify that the patterns must >> _always_ be fully-qualified, but may end with a single "/*" to iterate >> over wildcards. Or even simpler, that "refs/heads/foo" would find that >> ref

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-26 Thread Ævar Arnfjörð Bjarmason
On Sat, Feb 24 2018, Jeff King jotted: > On Thu, Feb 22, 2018 at 04:45:14PM -0800, Brandon Williams wrote: >> > Does the client have to be aware that we're using wildmatch? I think >> > they'd need "refs/heads/**" to actually implement what we usually >> > specify in refspecs as "refs/heads/*".

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-26 Thread Junio C Hamano
Jeff King writes: > I actually wonder if we should just specify that the patterns must > _always_ be fully-qualified, but may end with a single "/*" to iterate > over wildcards. Or even simpler, that "refs/heads/foo" would find that > ref itself, and anything under it. > > That

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-23 Thread Jeff King
On Fri, Feb 23, 2018 at 04:19:54PM -0800, Brandon Williams wrote: > > We always have the ability to extend the patterns accepted via a feature > > (or capability) to ls-refs, so maybe the best thing to do now would only > > support a few patterns with specific semantics. Something like if you >

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-23 Thread Jeff King
On Thu, Feb 22, 2018 at 04:45:14PM -0800, Brandon Williams wrote: > > This kind of tail matching can't quite implement all of the current > > behavior. Because we actually do the normal dwim_ref() matching, which > > includes stuff like "refs/remotes/%s/HEAD". > > > > The other problem with

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-23 Thread Brandon Williams
On 02/22, Brandon Williams wrote: > On 02/22, Jeff King wrote: > > On Tue, Feb 06, 2018 at 05:12:50PM -0800, Brandon Williams wrote: > > > > > +ls-refs takes in the following parameters wrapped in packet-lines: > > > + > > > +symrefs > > > + In addition to the object pointed by it, show the

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-22 Thread Brandon Williams
On 02/22, Jeff King wrote: > On Tue, Feb 06, 2018 at 05:12:50PM -0800, Brandon Williams wrote: > > > +ls-refs takes in the following parameters wrapped in packet-lines: > > + > > +symrefs > > + In addition to the object pointed by it, show the underlying ref > > + pointed by it when

Re: [PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-22 Thread Jeff King
On Tue, Feb 06, 2018 at 05:12:50PM -0800, Brandon Williams wrote: > +ls-refs takes in the following parameters wrapped in packet-lines: > + > +symrefs > + In addition to the object pointed by it, show the underlying ref > + pointed by it when showing a symbolic ref. > +peel > +

[PATCH v3 13/35] ls-refs: introduce ls-refs server command

2018-02-06 Thread Brandon Williams
Introduce the ls-refs server command. In protocol v2, the ls-refs command is used to request the ref advertisement from the server. Since it is a command which can be requested (as opposed to mandatory in v1), a client can sent a number of parameters in its request to limit the ref advertisement