From: Lessley Dennington Date: Tue, 04 Jan 2022 19:19:17 GMT Subject: Re: [PATCH 1/2] sparse-checkout: custom tab completion tests Message-ID: In-Reply-To: On 12/31/21 1:27 PM, Elijah Newren wrote: > On Fri, Dec 31, 2021 at 2:30 AM Derrick Stolee 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 -> folder >>>> folder1/ -> folder1/0 >>>> folder1/0/ -> 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 > > 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. Thank you for the feedback! This is fine by me - I'll respond further to your comments in [1]. [1] https://lore.kernel.org/git/CABPp-BG_Jgyr89z_D355Ytzz31J40nBGX=2cr+aXtcf3U1y6Dg@mail.gmail.com/