On Tue, Jan 29, 2019 at 12:27 AM Jeff King <peff@xxxxxxxx> wrote: > > On Mon, Jan 28, 2019 at 03:38:28PM +0100, SZEDER Gábor wrote: > > > > - __gitcomp_direct "$(__git_refs "$remote" "$track" "$pfx" "$cur_" "$sfx")" > > > + __gitcomp_direct "$(__git_refs "$remote" "$track" "$pfx" "$cur_" "$sfx" | __git_collapse_refs "$cur_")" > > > } > > > > 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. > > '%(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. > Doing that requires actually understanding that the refs are in a list, > and not formatting each one independently. So I kind of wonder if it > would be easier to simply have a completion mode in for-each-mode. That also allows more complicated logic. I think sometimes completion code gets it wrong (I think it's often the case with rev/path ambiguation, but maybe dwim stuff too). And we already have all this logic in C. -- Duy
