On 10/18/2019 4:40 PM, SZEDER Gábor wrote: > On Fri, Oct 18, 2019 at 10:24:21PM +0200, SZEDER Gábor wrote: >> On Tue, Oct 15, 2019 at 01:56:02PM +0000, Derrick Stolee via GitGitGadget wrote: >>> From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >>> >>> The sparse-checkout builtin used 'git read-tree -mu HEAD' to update the >>> skip-worktree bits in the index and to update the working directory. >>> This extra process is overly complex, and prone to failure. It also >>> requires that we write our changes to the sparse-checkout file before >>> trying to update the index. >>> >>> Remove this extra process call by creating a direct call to >>> unpack_trees() in the same way 'git read-tree -mu HEAD' does. In >>> addition, provide an in-memory list of patterns so we can avoid >>> reading from the sparse-checkout file. This allows us to test a >>> proposed change to the file before writing to it. >> >> Starting with this patch there is an issue with locking the index: >> >> $ git init >> Initialized empty Git repository in /home/szeder/src/git/tmp/SC/.git/ >> $ >file > > $ git add file > > Forgot to copy that command... > >> $ git commit -m initial >> [master (root-commit) 5d80b9c] initial >> 1 file changed, 0 insertions(+), 0 deletions(-) >> create mode 100644 file >> $ ls .git/index.lock >> ls: cannot access '.git/index.lock': No such file or directory >> $ git sparse-checkout set nope >> warning: core.sparseCheckout is disabled, so changes to the sparse-checkout file will have no effect >> warning: run 'git sparse-checkout init' to enable the sparse-checkout feature >> error: Sparse checkout leaves no entry on working directory >> fatal: Unable to create '/home/szeder/src/git/tmp/SC/.git/index.lock': >> File exists. >> >> Another git process seems to be running in this repository, e.g. >> an editor opened by 'git commit'. Please make sure all processes >> are terminated then try again. If it still fails, a git process >> may have crashed in this repository earlier: >> remove the file manually to continue. >> $ ls .git/index.lock >> ls: cannot access '.git/index.lock': No such file or directory > > I would add that building the previous patch and running the same > sequence of commands works, in the sense that 'git sparse-checkout > set' writes the non-existing filename to the 'sparse-checkout' file > and it prints the same two warnings, and doesn't (seem to) attempt to > update the working tree and the index. Thank you for catching this! The issue is that I was not rolling the index back on this kind of failed update, and then trying to replay the "old" sparse-checkout hit the existing .git/index.lock file. Here is the test I added that breaks on the current patch, but passes when adding a rollback_lock_file() call: test_expect_success 'revert to old sparse-checkout on empty update' ' git init empty-test && ( echo >file && git add file && git commit -m "test" && test_must_fail git sparse-checkout set nothing 2>err && test_i18ngrep "Sparse checkout leaves no entry on working directory" err && test_i18ngrep ! ".git/index.lock" err && git sparse-checkout set file ) ' It also has the following problem: because we are setting the patterns in-memory, this update acts like core.sparseCheckout is enabled, even when it is not. So, I'm finally convinced that the 'set' command should enable the config setting if it is called even without 'init'. Thanks, -Stolee
