On Fri, Dec 31, 2021 at 2:30 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 12/30/2021 11:19 AM, Lessley Dennington wrote: > > On 12/30/21 7:43 AM, Derrick Stolee wrote: > > >>> + ( > >>> + cd sparse-checkout && > >>> + test_completion "git sparse-checkout set f" <<-\EOF > >>> + folder1 Z > >>> + folder1/0 Z > >>> + folder1/0/1 Z > >>> + folder2 Z > >>> + folder2/0 Z > >>> + folder3 Z > >> > >> This tab-completion doing a full directory walk seems like it could > >> be expensive for a large repository, but I suppose it is the only way > >> to allow the following sequence: > >> > >> fol<tab> -> folder > >> folder1/<tab> -> folder1/0 > >> folder1/0/<tab> -> folder1/0/1 > >> > >> (Hopefully that makes sense.) > >> > > Yes, it does. > >> It would be more efficient to only go one level deep at a time, but > >> that might not be possible with the tab completion mechanisms. > >> > > When you say one level deep, do you mean that from the sparse-checkout > > directory, tab completion would only show the following? > > > > folder1 > > folder2 > > folder3 > > That's what I mean by one level deep at a time, but I also am not > sure that that is the correct functionality. I would leave the full > expansion as you have now as the design. I think one level at a time is better and is the optimal design. By way of comparison, note that if I do the following: mkdir tmp cd tmp mkdir -p a/b/c/d touch a/b/c/d/e cd <TAB> I do not see a/b/c/d as the completion, I only get "a/" as the completion. If I hit tab again, then I get "a/b/". Tab again, and I get "a/b/c/". I don't think normal tab completion recursively checks directories, so it'd be better for us to not do so with git either. However, if it's hard to avoid automatically completing just a directory at a time, then I think a fair first cut is completing to full depths, but call it out as something we'd like to fix in the commit message.
