On Tue, Mar 24, 2020 at 11:30 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > > On Mon, Mar 23, 2020 at 11:13 PM Matheus Tavares > > <matheus.bernardino@xxxxxx> wrote: > >> > >> In the last commit, git-grep learned to honor sparsity patterns. For > >> some use cases, however, it may be desirable to search outside the > >> sparse checkout. So add the '--ignore-sparsity' option, which restores > >> the old behavior. Also add the grep.ignoreSparsity configuration, to > >> allow setting this behavior by default. > > > > Should `--ignore-sparsity` be a global git option rather than a > > grep-specific one? Also, should grep.ignoreSparsity rather be > > core.ignoreSparsity or core.searchOutsideSparsePaths or something? > > Great question. I think "git diff" with various options would also > want to optionally be able to be confined within the sparse cone, or > checking the entire world by lazily fetching outside the sparsity. > > > * grep, diff, log, shortlog, blame, bisect (and maybe others) all by > > default make use of the sparsity patterns to limit their output (but > > can all use whatever flag(s) are added here to search outside the > > sparsity pattern cones). This helps users feel they are in a smaller > > repo and searching just their area of interest, and it avoids partial > > clones downloading blobs unnecessarily. Nice for the user, and nice > > for the system. > > I am not sure which one should be the default. From historical > point of view that sparse stuff was done as an optimization to omit > initial work and lazily give the whole world, I may have slight > preference to the "we pretend that you have everything, just some > parts may be slower to come to you" world view to be the default, > with an option to limit the view to whatever sparsity you initially > set up. It sounds like you are describing partial clone rather than sparse checkout? Or perhaps you're trying to blur the distinction, suggesting the two should be used together, with the partial clone machinery learning to download history within the specified sparse cones? > Regardless of the choice of the default, it would be a good > idea to make the subcommands consistently offer the same default and > allow the non-default views with the same UI. Agreed.
