Message ID | pull.1018.v2.git.1631453010.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Sparse-checkout: modify 'git add', 'git rm', and 'git add' behavior | expand |
On Sun, Sep 12, 2021 at 6:23 AM Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com> 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. > > This means that commands that worked before this series can now fail. In > particular, if 'git merge' results in a conflict outside of the > sparse-checkout cone, then 'git add ' will now fail. > > In order to allow users to circumvent these protections, a new '--sparse' > option is added that ignores the sparse-checkout patterns and the > SKIP_WORKTREE bit. The message for advice.updateSparsePath is adjusted to > assist with discovery of this option. > > There is a subtle issue with git mv in that it does not check the index > until it discovers a directory and then uses the index to find the contained > entries. This means that in non-cone-mode patterns, a pattern such as > "sub/dir" will not match the path "sub" and this can cause an issue. > > In order to allow for checking arbitrary paths against the sparse-checkout > patterns, some changes to the underlying pattern matching code is required. > It turns out that there are some bugs in the methods as advertised, but > these bugs were never discovered because of the way methods like > unpack_trees() will check a directory for a pattern match before checking > its contained paths. Our new "check patterns on-demand" approach pokes holes > in that approach, specifically with patterns that match entire directories. > > > Updates in v2 > ============= > > * I got no complaints about these restrictions, so this is now a full > series, not RFC. > > * Thanks to Matheus, several holes are filled with extra testing and > bugfixes. > > * New patches add --chmod and --renormalize improvements. These are added > after the --sparse option to make them be one change each. Sorry for taking so long, but I finally read through the series. Only had a few small comments here and there; the high level direction looks good.
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. 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 $ git read-tree -mu HEAD $ rm arch/x86/kvm/x86.c $ git commit -a On branch x86/kvm_find_cpuid_entry_index Your branch is up to date with 'kvm/queue'. You are in a sparse checkout with 40% of tracked files present. Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) deleted: arch/x86/kvm/x86.c no changes added to commit (use "git add" and/or "git commit -a") $ git add arch $ git add . $ git add arch/x86 The following paths and/or pathspecs matched paths that exist outside of your sparse-checkout definition, so will not be updated in the index: arch/x86 hint: If you intend to update such entries, try one of the following: hint: * Use the --sparse option. hint: * Disable or modify the sparsity rules. hint: Disable this message with "git config advice.updateSparsePath false"
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. 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. > $ 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. Thanks, -Stolee
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!
Sean Christopherson <seanjc@google.com> writes: >> 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. $ git version Guessing from the e-mail address, perhaps you are using something derived from the next branch of the day, maintained by Jonathan Nieder's group, for internal consumption at Google.
On Wed, Oct 20, 2021, Junio C Hamano wrote: > Sean Christopherson <seanjc@google.com> writes: > > >> 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. > > $ git version > > Guessing from the e-mail address, perhaps you are using something > derived from the next branch of the day, maintained by Jonathan > Nieder's group, for internal consumption at Google. That's more than likely the case. 2.33.0.1079.g6e70778dc9-goog