Re: [PATCH v4] sparse-checkout.txt: new document with sparse-checkout directions

[ZheNing Hu <adlternative@gmail.com>]

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?