From: Junio C Hamano <gitster@pobox.com>
To: Victoria Dye <vdye@github.com>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Derrick Stolee <derrickstolee@github.com>,
Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>,
Matheus Tavares <matheus.bernardino@usp.br>,
ZheNing Hu <adlternative@gmail.com>,
Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH] sparse-checkout.txt: new document with sparse-checkout directions
Date: Mon, 26 Sep 2022 15:36:09 -0700 [thread overview]
Message-ID: <xmqqv8p9ahly.fsf@gitster.g> (raw)
In-Reply-To: <a89413b5-464b-2d54-5b8c-4502392afde8@github.com> (Victoria Dye's message of "Mon, 26 Sep 2022 13:08:59 -0700")
Victoria Dye <vdye@github.com> writes:
>> +* Commands behaving the same regardless of high-level use-case
>> +
>> + * commands that only look at files within the sparsity specification
>> +
>> + * status
>> + * diff (without --cached or REVISION arguments)
>> + * grep (without --cached or REVISION arguments)
>
> 'status' and 'diff' currently show information about untracked files outside
> the working tree (since, not being in the index, they don't have a
> 'SKIP_WORKTREE' to use). Should that change with the proposed '--restrict'
> option?
Most likely not. When sparsity specification is in effect, as you
said elsewhere in your response, no files, whether tracked or
untrcked, should exist that are outside your area of interest.
Their presence should be reported as anomalies by "git status".
Unless the command is being run with the "-uno" option, that is.
> - 'switch', 'checkout' (switch-like), and 'read-tree -m' block the operation
> & advise on how to clean up the modified files to re-align with the
> sparsity patterns.
> - 'reset --hard' silently drops the modified file and resets the
> 'SKIP_WORKTREE' bit on the corresponding index entry.
>
> With the exception of 'reset --hard' (aggressively and unconditionally
> cleaning the worktree & index is an important aspect of the command, IMO),
> I'd personally like to see commands in this category align with the behavior
> of 'switch' where they don't already. Regardless of what we decide, though,
> I think it's probably worth documenting the "modified outside of sparsity
> patterns" case.
True. I agree on both counts.
> Also, 'read-tree' (no args) doesn't apply the 'SKIP_WORKTREE' bit to *any*
> of the entries it reads into the index. Having all of your files suddenly
> appear "deleted" probably isn't desired behavior, so it might be a good
> candidate for the "Known bugs" section.
I would imagine that it actually is OK to say that it is the
responsibility of whoever invokes read-tree the plumbing command
to reapply the skip-worktree bits and/or collapse the index entries
outside the area of interest into trees afterwards.
>> +* Commands that differ for behavior A vs. behavior B:
>> +
>> + * commands that make modifications:
>
> nit: "make modifications" -> "make modifications to the index"?
That clarification actually raises an interesting question. Do we
want three level distinction, i.e. different behaviour between
commands that touch and do not touch the working tree, between those
that touch and do not touch the index, and between those that touch
and do not touch the commit?
As the index is merely a way to express what the user did to
eventually create the next tree to be recorded in the commit, my gut
feeling is that it may be easier to understand if we treated the
working tree and the index at the same level, actually. I.e. if
grepping in the working tree of a sparse checkout does not find a
match outside the cones of interest, it may make sense to do the
same at least by default in "grep --cached" mode.
If I understand Stolee's write-up on the use case of those in the
camp B, they are more aware of the larger whole and expect to see
hits outside the area they have checkout when running "grep HEAD".
But in their use case, they do not touch (only look) the area
outside their cone of interest, so if we limit the operation to
their cone of interest by default for working tree, the same default
probably should apply equally for an operation that inspect the
index.
next prev parent reply other threads:[~2022-09-26 22:36 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-25 0:09 [PATCH] sparse-checkout.txt: new document with sparse-checkout directions Elijah Newren via GitGitGadget
2022-09-26 17:20 ` Junio C Hamano
2022-09-26 17:38 ` Junio C Hamano
2022-09-27 3:05 ` Elijah Newren
2022-09-27 4:30 ` Junio C Hamano
2022-09-26 20:08 ` Victoria Dye
2022-09-26 22:36 ` Junio C Hamano [this message]
2022-09-27 7:30 ` Elijah Newren
2022-09-27 16:07 ` Junio C Hamano
2022-09-28 6:13 ` Elijah Newren
2022-09-27 6:09 ` Elijah Newren
2022-09-27 16:42 ` Derrick Stolee
2022-09-28 5:42 ` Elijah Newren
2022-09-27 15:43 ` Junio C Hamano
2022-09-28 7:49 ` Elijah Newren
2022-09-27 16:36 ` Derrick Stolee
2022-09-28 5:38 ` Elijah Newren
2022-09-28 13:22 ` Derrick Stolee
2022-10-06 7:10 ` Elijah Newren
2022-10-06 18:27 ` Derrick Stolee
2022-10-07 2:56 ` Elijah Newren
2022-09-30 9:54 ` ZheNing Hu
2022-10-06 7:53 ` Elijah Newren
2022-10-15 2:17 ` ZheNing Hu
2022-10-15 4:37 ` Elijah Newren
2022-10-15 14:49 ` ZheNing Hu
2022-09-30 9:09 ` ZheNing Hu
2022-09-28 8:32 ` [PATCH v2] " Elijah Newren via GitGitGadget
2022-10-08 22:52 ` [PATCH v3] " Elijah Newren via GitGitGadget
2022-11-06 6:04 ` [PATCH v4] " Elijah Newren via GitGitGadget
2022-11-07 20:44 ` Derrick Stolee
2022-11-16 4:39 ` Elijah Newren
2022-11-15 4:03 ` ZheNing Hu
2022-11-16 3:18 ` ZheNing Hu
2022-11-16 6:51 ` Elijah Newren
2022-11-16 5:49 ` Elijah Newren
2022-11-16 10:04 ` ZheNing Hu
2022-11-16 10:10 ` ZheNing Hu
2022-11-16 14:33 ` ZheNing Hu
2022-11-19 2:36 ` Elijah Newren
2022-11-19 2:15 ` Elijah Newren
2022-11-23 9:08 ` ZheNing Hu
2023-01-14 10:18 ` ZheNing Hu
2023-01-20 4:30 ` Elijah Newren
2023-01-23 15:05 ` ZheNing Hu
2023-01-24 3:17 ` Elijah Newren
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=xmqqv8p9ahly.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=adlternative@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=matheus.bernardino@usp.br \
--cc=newren@gmail.com \
--cc=shaoxuan.yuan02@gmail.com \
--cc=vdye@github.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).