On Wed, Nov 16, 2022 at 6:33 AM ZheNing Hu <adlternative@xxxxxxxxx> wrote: > > ZheNing Hu <adlternative@xxxxxxxxx> 于2022年11月16日周三 18:10写道： > > > > ZheNing Hu <adlternative@xxxxxxxxx> 于2022年11月16日周三 18:04写道： > > > > > > Elijah Newren <newren@xxxxxxxxx> 于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@xxxxxxxxxxxxxx/ > > > > (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
