Re: [PATCH/RFC] completion: complete refs in multiple steps

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Jan 29, 2019, 15:36 UTC
Message-ID: <20190129153650.GB13764@szeder.dev>
In-Reply-To: <CACsJy8BXfY+bZKV6Jxa7-3VQyyE6hGrFS7ZAnToFwpGq_o1bpw@mail.gmail.com>

On Tue, Jan 29, 2019 at 07:43:45AM +0700, Duy Nguyen wrote:

> On Tue, Jan 29, 2019 at 12:27 AM Jeff King <peff@peff.net> wrote:

Show 9 quoted lines

> > > In general I think it would be much better to rely more on 'git
> > > for-each-ref' to do the heavy lifting, extending it with new format
> > > specifiers/options as necessary.
> >
> > FWIW, that was my first thought, too.
> 
> I was more concerned whether it's a good idea to begin with. But it
> sounds like you two both think it's good otherwise would have
> objected.

Well, I objected to this RFC implementation, but on purpose refrained from expressing an opinion about whether this is good or bad idea, because I didn't even want to try to guess what others might prefer :)

And as far as I can tell it doesn't affect my usage (in general I don't have multi-level hierarchies under refs/heads/, so I mostly complete a single ref path component, and when on occasion I do complete a full ref, then I tend to know what I want, and even if I don't, I only need the list of possibilities only at the last ref path component).

Show 28 quoted lines

> > > '%(refname:rstrip=-<N>)' already comes somewhat close to what we would
> > > need for full ref completion (i.e. 'refs/b<TAB>' to complete
> > > 'refs/bisec/bad'), we only have to figure out how many "ref path
> > > components" to show based on the number of path components in the
> > > current word to be completed.  Alas, it won't add the trailing '/' for
> > > "ref directories".
> >
> > I think it also makes it hard to do one thing which (I think) people
> > would want: if there is a single deep ref, complete the whole thing.
> > E.g., given:
> >
> >   $ git for-each-ref --refname='%(refname)'
> >   refs/heads/foo/bar
> >   refs/heads/foo/baz
> >   refs/heads/another/deep/one
> >
> > we'd ideally complete "fo" to "foo/" and "ano" to "another/deep/one",
> > rather than making the user tab through each level.
> 
> Ah ha, like github sometimes show nested submodule paths. Just one
> small modification, when doing "refs/heads/<tab>" I would just show
> 
> refs/heads/foo/
> refs/heads/another/
> 
> not refs/heads/another/deep/one to save space. But when you do
> "refs/heads/a<tab>" then you get "refs/heads/another/deep/one"
> immediately.

But this would be inconsistent with how "regular" path completion works, e.g. if you have 'unique-dir/only-one-dir/only-one-file' and do e.g. 'cat u<TAB>', then Bash will only offer 'unique-dir/', not the whole path to the file in the subdir. Ok, I know, those are real paths not refs, they just look alike, because both happen to use '/' as separator.

I can't asses whether people, in general, would prefer this behavior or would rather be surprised or bothered by the inconsistency.