On Sat, Jan 15, 2022 at 05:03:24PM -0800, Elijah Newren wrote:

On Sat, Jan 15, 2022 at 1:57 AM SZEDER Gábor [off-list ref] wrote:

quoted

On Mon, Jan 10, 2022 at 06:59:51PM +0000, Lessley Dennington via GitGitGadget wrote:

quoted

Subject: Re: [PATCH v3 2/3] sparse-checkout: custom tab completion

None of these patches touch sparse-checkout, but only the completion
script and its tests.  Therefore "completion:" would be a better
matching area prefix.

Thanks for the detailed feedback and guidance in your review.  Very
helpful.  I'll omit quoting most of it here, but I do want to comment
on the point about directories.

...

quoted

quoted

4. A list of directories (but not files) is provided when users enter git
sparse-checkout add <TAB> or git sparse-checkout set <TAB>.

Why limit completion only to directories?  Both of those subcommands
accept files,

Discussed in part at [1], but let me give a more detailed answer.

It was a semi-rhetorical question.  Whether the reasons for expluding
files are sound or not, it should be convincingly justified in the
commit message.

Both of these commands accept not only directories and files, but also
nearly arbitrary input as far as I can tell.  (In cone-mode, it'll
accept anything so long as it doesn't look like a relative path that
tries to reach above the toplevel directory with '../' sequences.  In
non-cone mode, I think it accepts completely arbitrary input).  If our
guide is merely what the command swallows, then we should forgo
completion for these subcommands, because it's not possible to
enumerate all possible completions.  I don't think that's a useful
guide or starting point, so we instead need to discuss what are
reasonable completions.

cone-mode works exclusively on directories.  So, in that mode,
directories are what we want to complete on.  (And if a file is
specified, cone-mode will treat it as a directory and add expressions
for including all the files under that "directory", which might be
confusing.  sparse-checkout doesn't verify it is a diretory, because
it *might* name a directory in a different branch, including one not
yet downloaded.  But "might name a directory on another branch" is no
reason to suggest picking that pathname with completion.)

In non-cone mode, arbitrary expressions are valid and will be treated
as gitignore-style expressions.  That again leaves us with either not
providing completions, or choosing a subset of possible inputs that
are reasonable suggestions for users.  I prefer the latter, and in
particular I feel that directories are reasonable suggestions.  In
contrast, I don't think providing files is helpful, because it
reinforces the design flaw of non-cone mode.  Non-cone mode has
quadratic performance baked into its design, and since
sparse-checkouts are about performance, non-cone mode kind of defeats
the purpose of the command.

Or about disk space.  Which, because of the potentially significantly
reduced number of files in the work tree can bring along significant
performance benefits, even with quadratic behavior.

 (In addition to other problems[2].)  So,
I think non-cone mode should be deprecated and excised.  Patches
elsewhere are moving in the direction of deprecation already[3], and
we've already discussed multiple steps we'll likely take soon
continuing in that direction.  In the meantime, providing just
directories for completion seems like a good direction to me.

[1] https://lore.kernel.org/git/CABPp-BG=wr81CPtW1M12xFN_0dyS8mAZjM6o=77LA20Zge8Xng@mail.gmail.com/ (local)
[2] https://lore.kernel.org/git/CABPp-BF=-1aZd=nFHF6spo7Ksa7f7Wb7ervCt0QvtNitMY=ZBA@mail.gmail.com/ (local)
[3] https://lore.kernel.org/git/0af00779128e594aff0ee4ec5378addeac8e88a2.1642175983.git.gitgitgadget@gmail.com/ (local)
("This mode is harder to use and less performant, and is thus not
recommended.")

quoted

and I think 'git sparse-checkout set README.md' is a
perfectly reasonable command.

Reasonable in what sense?  That it makes it (vastly) easier to
implement the completion and sparse-checkout set|add will swallow it,
or that it's something that should actually be recommended for users
doing sparse-checkouts?  While the former certainly holds, I don't
think the latter does.

I used the following command to create a sparse-checkout from
linux.git to build and play with 'perf':

  git sparse-checkout set tools/perf/ tools/scripts/ tools/build/ tools/include/ tools/arch/x86/ tools/lib/ /.gitignore /.gitattributes

Including the top-level '.gitignore' and '.gitattributes' was
important, becase those ignore object files and specify userdiff.
Now, I wouldn't mind having other files present in the top-level
directory, because there are only a handful of files there.  However,
being able to specify just those two files to 'git sparse-checkout'
was great, because I didn't even have to think about what wildcard
pattern to use, and what negative pattern to use to exclude anything
that might have been included recursively.

I don't remember having any performance issues with it, on the
contrary, I do remember that Git suddenly became much faster that in
the full worktree.

So I'm fairly convinced that specifying files to sparse-checkout is a
feature that can make users' life easier.  It certainly made my life
easier.


On a related note: I just noticed the leading slashes in '/.gitignore'
and '/.gitattributes'.  __git_complete_index_file() is not ready for
that, I'm afraid; but I don't think the proposed patches could deal
with that, either (but I didn't actually try).

It would be great if completion could cope with patterns starting with
'/' and/or '!'.