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 > 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). > > > '%(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.
