git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Victoria Dye <vdye@github.com>
To: William Sprent <williams@unity3d.com>,
	William Sprent via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Cc: "Eric Sunshine" <sunshine@sunshineco.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Derrick Stolee" <derrickstolee@github.com>,
	"Elijah Newren" <newren@gmail.com>
Subject: Re: [PATCH v2] ls-tree: add --sparse-filter-oid argument
Date: Wed, 25 Jan 2023 10:32:37 -0800	[thread overview]
Message-ID: <42e14dda-cd2b-09df-dea8-246b3fcfac42@github.com> (raw)
In-Reply-To: <569043fb-9766-037e-c587-1545c2978e7d@unity3d.com>

William Sprent wrote:
> On 24/01/2023 21.11, Victoria Dye wrote>> I haven't looked at your implementation in detail yet, but I did want to
>> offer a recommendation in case you hadn't considered it: if you want to
>> allow the use of patterns from a user-specified specific file, it would be
>> nice to do it in a way that fully replaces the "default" sparse-checkout
>> settings at the lowest level (i.e., override the values of
>> 'core_apply_sparse_checkout', 'core_sparse_checkout_cone', and
>> 'get_sparse_checkout_filename()'). Doing it that way would both make it
>> easier for other commands to add a '--sparse-patterns' option, and avoid the
>> separate code path ('path_in_sparse_checkout_1()' vs.
>> 'recursively_match_path_with_sparse_patterns()', for example) when dealing
>> with '.git/info/sparse-checkout' patterns vs. manually-specified patterns.
>>
> 
> Thanks for the pointers. I'll see what I can do. Do you mean something
> along the line of the following?
> 
>    set_sparse_checkout_file(filename);
>    init_sparse_checkout_patterns(istate);
>    _ = path_in_sparse_checkout_1(some_path, istate, ...);
> 

Sort of. I mentioned separating the options into "specify the sparse pattern
file" and "restrict the displayed files to the active pattern set, if there
is one". For the former, you might add an option like:

	OPT_FILENAME(0, "sparse-patterns", &sparse_pattern_file, 
		     N_("override sparse-checkout behavior using patterns from <file>"))

Then do something like what you have, right after option parsing:

	if (sparse_pattern_file) {
		core_apply_sparse_checkout = 1;
		core_sparse_checkout_cone = <???>;
		set_sparse_checkout_file(filename);
	}

If this option is specified, but the repo already has sparse
patterns/settings of its own, you'll need to (carefully) override the repo's
existing configuration:

* 'core_apply_sparse_checkout' & 'core_sparse_checkout_cone' are set based
  on the repo config. You'll need to make sure those values are overridden
  before loading the sparse-checkout patterns, and also that they're set
  *after* loading the config.
* Speaking of 'core_sparse_checkout_cone', there are a bunch of ways you
  might configure "cone-" vs. "non-cone" for your patterns (user-specified
  with yet another option, always assume one or the other, try deriving from
  the patterns). My preference would be to always assume "cone mode" - it's
  the direction Git has been moving with sparse-checkout over the past year,
  and still automatically "falls back" on non-cone patterns if the patterns
  can't be used in cone mode (with a warning from
  'add_pattern_to_hashsets()': "disabling cone pattern matching").
* If the repo is using a sparse index, the existing sparse directories may
  not be compatible with the custom patterns. Probably easiest to force use
  of a full index, e.g. with 'command_requires_full_index = 1'.

Fair warning: this probably isn't an exhaustive list of things that would
need updating, and it'll need thorough testing to make sure there are no
regressions. But, extending the underlying sparse-checkout infrastructure
will (ideally) avoid duplicating code and make this behavior reusable across
other commands.

For the other desired behavior ("limit the files to the active
sparse-checkout patterns"), you could add an option:

	OPT_CALLBACK_F(0, "scope", &sparse_scope, "(sparse|all)",
		       N_("specify the scope of results with respect to the sparse-checkout"),
		       PARSE_OPT_NONEG, option_parse_scope),

...whose callback parses the string arg into a 'restrict_scope'
boolean/enum/something. Then, wherever in 'ls-files' a tree or the index are
iterated over, you can gate the per-file operation on:

	if (!restrict_scope || path_in_sparse_checkout(<path>, istate)) {
		/* do something with <path> */
	}

Note that you should use 'path_in_sparse_checkout()', *not* the
internal/private function 'path_in_sparse_checkout_1()'; you also don't need
to explicitly 'init_sparse_checkout_patterns()'. Regardless of whether you
specified custom patterns or are using the ones in
'.git/info/sparse-checkout', 'path_in_sparse_checkout()' will initialize &
use the appropriate patterns.


  reply	other threads:[~2023-01-25 18:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-11 17:01 [PATCH] ls-tree: add --sparse-filter-oid argument William Sprent via GitGitGadget
2023-01-13 14:17 ` Eric Sunshine
2023-01-13 20:01   ` Junio C Hamano
2023-01-16 15:13     ` William Sprent
2023-01-16 12:14   ` William Sprent
2023-01-23 11:46 ` [PATCH v2] " William Sprent via GitGitGadget
2023-01-23 13:00   ` Ævar Arnfjörð Bjarmason
2023-01-24 15:30     ` William Sprent
2023-01-23 13:06   ` Ævar Arnfjörð Bjarmason
2023-01-24 15:30     ` William Sprent
2023-01-24 20:11   ` Victoria Dye
2023-01-25 13:47     ` William Sprent
2023-01-25 18:32       ` Victoria Dye [this message]
2023-01-26 14:55         ` William Sprent
2023-01-25  5:11   ` Elijah Newren
2023-01-25 16:16     ` William Sprent
2023-01-26  3:25       ` Elijah Newren
2023-01-27 11:58         ` William Sprent
2023-01-28 16:45           ` Elijah Newren
2023-01-30 15:28             ` William Sprent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42e14dda-cd2b-09df-dea8-246b3fcfac42@github.com \
    --to=vdye@github.com \
    --cc=avarab@gmail.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=newren@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=williams@unity3d.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).