git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elijah Newren <newren@gmail.com>
To: ZheNing Hu <adlternative@gmail.com>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Victoria Dye <vdye@github.com>,
	Derrick Stolee <derrickstolee@github.com>,
	Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>,
	Matheus Tavares <matheus.bernardino@usp.br>,
	Glen Choo <chooglen@google.com>,
	Martin von Zweigbergk <martinvonz@google.com>
Subject: Re: [PATCH v4] sparse-checkout.txt: new document with sparse-checkout directions
Date: Fri, 18 Nov 2022 18:36:00 -0800	[thread overview]
Message-ID: <CABPp-BEvJWAWkKsknAqYVs16GuStmgzetkHXiSgqkYLdAhfPPw@mail.gmail.com> (raw)
In-Reply-To: <CAOLTT8S8e_0LaEFLD4B4F=u9cKPtdPvp7tWJoEf3Z4Z9Bw6SUw@mail.gmail.com>

On Wed, Nov 16, 2022 at 6:33 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> ZheNing Hu <adlternative@gmail.com> 于2022年11月16日周三 18:10写道:
> >
> > ZheNing Hu <adlternative@gmail.com> 于2022年11月16日周三 18:04写道:
> > >
> > > Elijah Newren <newren@gmail.com> 于2022年11月16日周三 13:49写道:
> > > >
> > > > Perhaps it's worth noting why I think the sparse specification should
> > > > be extended when dealing with the index:
> > > >
> > > >   * "mergy" commands (merge, rebase, cherry-pick, am, revert) can
> > > > modify the index outside the sparsity patterns, without creating a
> > > > commit.
> > > >   * `git commit` (or `rebase --continue`, or whatever) will create a
> > > > commit from whatever staged versions of files there are
> > > >   => `git status` should show what is about to be committed
> > > >   => `git diff --cached --name-only` ought to be usable to show what
> > > > is to be committed
> > > >   => `git grep --cached ...` ought to be usable to search through what
> > > > is about to be committed
> > > >
> > > > See also https://lore.kernel.org/git/CABPp-BESkb=04vVnqTvZyeCa+7cymX7rosUW3rhtA02khMJKHA@mail.gmail.com/
> > > > (starting with the paragraph with "leery" in it), and the thread
> > > > starting there.  If the sparse specification is not expanded, users
> > > > will get some nasty surprises, and the only other alternative I can
> > > > think of to avoid such surprises would be making several commands
> > > > always run full tree.  Running full-tree with a non-default option to
> > > > run sparse forces behavior A folks into a "pick your poison"
> > > > situation, which is not nice.  Extending the sparse specification to
> > > > include files whose index entries do not match HEAD for index-related
> > > > operations provides the nice middle ground that avoids such usability
> > > > problems while also allowing users to avoid operating on a full tree.
> > > >
> > >
> > > I can understand the reason why we need to extend sparse specification:
> > > index often needs to handle files that are not in the sparse pattern.
> > >
> >
> > I might have one more question: when we use "git diff -cached HEAD~",
> > what is the best way to check if an index entry is the same as HEAD here?
> > Do we need to run "git diff --cached HEAD <file>" again?
>
> I found that git commit will execute index_differs_from() to determine
> whether the index has changed, It defaults to comparing HEAD.
> But if we use git commit --amend, index_differs_from() will compare
> to HEAD~.
>
> the docs say:
>
>        * When modifying or showing results from the index, the sparse
>          specification is the set of files with a clear SKIP_WORKTREE bit
>          or that differ in the index from HEAD.
>
> I wonder if there is some description error here? Not always "from HEAD"?

Perhaps this part of the document will help:

+  * commands that always ignore sparsity since commits must be full-tree
+
+      * archive
+      * bundle
+      * commit
+      * format-patch
+      * fast-export
+      * fast-import
+      * commit-tree

  reply	other threads:[~2022-11-19  2:51 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
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 [this message]
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

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

  git send-email \
    --in-reply-to=CABPp-BEvJWAWkKsknAqYVs16GuStmgzetkHXiSgqkYLdAhfPPw@mail.gmail.com \
    --to=newren@gmail.com \
    --cc=adlternative@gmail.com \
    --cc=chooglen@google.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=martinvonz@google.com \
    --cc=matheus.bernardino@usp.br \
    --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.
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 NNTP newsgroup(s).