Re: [PATCH v2 00/14] Sparse-checkout: modify 'git add', 'git rm', and 'git add' behavior

[Sean Christopherson <seanjc@google.com>]

On Tue, Oct 19, 2021, Derrick Stolee wrote:
> On 10/18/2021 5:28 PM, Sean Christopherson wrote:
> > On Sun, Sep 12, 2021, Derrick Stolee via GitGitGadget wrote:
> >> This series is based on ds/mergies-with-sparse-index.
> >>
> >> As requested, this series looks to update the behavior of git add, git rm,
> >> and git mv when they attempt to modify paths outside of the sparse-checkout
> >> cone. In particular, this care is expanded to not just cache entries with
> >> the SKIP_WORKTREE bit, but also paths that do not match the sparse-checkout
> >> definition.
> > 
> > I suspect something in this series broke 'git add' and friends with "odd" sparse
> > definitions (I haven't actually bisected).  git 2.33.0 rejects attempts to add
> > files with the below sparse-checkout and modified files.  There appears to be a
> > discrepancy in the query vs. checkout logic as the rejected files are checked out
> > in the working tree, e.g. git sees that the local file was deleted, yet will not
> > stage the deletion.
> 
> Are you using v2.33.0? This change is not in that version.

Hrm, it's an internal build that says v2.33.0 is the bsae, but the --sparse option
is available so who knows what's actually underneath the hood.  I can try vanilla
upstream builds if that would help narrow down the issue.

> However, mt/add-rm-in-sparse-checkout [1] was introduced in v2.33.0 and
> introduced these advice suggestions.
> 
> [1] https://github.com/git/git/compare/a5828ae6b52137b913b978e16cd2334482eb4c1f...d5f4b8260f623d6fdef36d5eaa8a0c2350390472
>
> The series you are commenting on goes even farther in restricting adds to
> be within the sparse-checkout definitions, even for unstaged files or files
> that removed the skip-worktree bit due to a merge conflict. It also creates
> an override '--sparse' option that allows you to ignore these protections.
> 
> > There's also arguably a flaw in the "advise" trigger.  AFAICT, the help message
> > is displayed if and only if the entire path is excluded from the working tree.
> > In my perfect world, git would complain and advise if there are unstaged changes
> > for tracked files covered by the specified path.
> >> Note, my sparse-checkout is very much the result of trial and error to get the
> > exact files I care about.  It's entirely possible I'm doing something weird, but
> > at the same time git itself is obviously confused.
> > 
> > Thanks!
> > 
> > $ cat .git/info/sparse-checkout
> > !arch/*
> > !tools/arch/*
> > !virt/kvm/arm/*
> > /*
> > arch/.gitignore
> > arch/Kconfig
> > arch/x86
> > tools/arch/x86
> > tools/include/uapi/linux/kvm.h
> > !Documentation
> > !drivers
> 
> Have you tried using 'arch/x86/' and 'tools/arch/x86/' to specify
> that these are directories? Just a thought.

Nice!  That workaround resolves the issue.  I vaguely recall intentionally omitting
the trailing slash, but adding it back doesn't seem to have any unwanted side effects
on the current git versions I'm using.

> > $ git read-tree -mu HEAD
> > 
> > $ rm arch/x86/kvm/x86.c
> > 
> > $ git commit -a
> ...
> > 	deleted:    arch/x86/kvm/x86.c
> 
> This is certainly odd. Worth more investigation that I don't have
> time for at this moment.

I've no objection to punting on this now that I have a workaround.  The man pages
are quite clear that sparse checkouts are still experimental and it's no trouble
for me to whine again if something breaks in the future :-)

Thanks again!