On 12/31/21 1:27 PM, Elijah Newren wrote:
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.
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@xxxxxxxxxxxxxx/
