Re: [PATCH/RFC] completion: complete refs in multiple steps
- Date: Tue, 29 Jan 2019 16:36:50 +0100
- From: SZEDER Gábor <szeder.dev@xxxxxxxxx>
- Subject: Re: [PATCH/RFC] completion: complete refs in multiple steps
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@xxxxxxxx> wrote:
> > > 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
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
> > > '%(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
> 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"
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 '/'
I can't asses whether people, in general, would prefer this behavior
or would rather be surprised or bothered by the inconsistency.