On 12/20/2021 11:21 AM, Eric Sunshine wrote: > On Mon, Dec 20, 2021 at 10:57 AM Derrick Stolee via GitGitGadget > <gitgitgadget@xxxxxxxxx> wrote: >> This patch series includes a fix to the bug reported by Sean Allred [1] and >> diagnosed by Eric Sunshine [2]. >> >> The root cause is that 'git sparse-checkout init' writes to the worktree >> config without checking that core.bare might need to be set. This only >> matters when the base repository is bare, since creating the config.worktree >> file and enabling extensions.worktreeConfig will cause Git to treat the base >> repo's core.bare=false as important for this worktree. > > Thanks for jumping on this so quickly. Unfortunately, however, as > mentioned in [1] and [2], I think the approach implemented here of > setting `core.bare=false` in the worktree-specific config is > fundamentally flawed since it only addresses the problem for worktrees > in which `git sparse-checkout init` has been run, but leaves all other > worktrees potentially broken (both existing and new worktrees). As far > as I can see, the _only_ correct solution is for the new helper > function to enable `extensions.worktreeConfig` _and_ relocate > `core.bare` and `core.worktree` from .git/config to > .git/worktree.config, thus implementing the requirements documented in > git-worktree.txt. Thanks for clarifying what I had misread. I commented on Patch 3 at the place that should be changed to relocate the setting. The test in patch 4 could have multiple worktrees to verify that it works. I'll plan on providing a v2 with that change tomorrow, leaving time to find any other glaring errors. > I also raised a separate question in [2] about whether `git > sparse-checkout init` or the new helper function should be warning the > user that upgrading the repository format and setting > `extensions.worktreeConfig` might break third-party tools. However, > that question is tangential to the fix being addressed here and > doesn't need to be addressed by this series. Let's continue to simmer on this one. If there is a clear direction for doing this (should it just be an advice message?) then we can do that whenever. > [1]: https://lore.kernel.org/git/CAPig+cQ6U_yFw-X2OWrizB1rbCvc4bNxuSzKFzmoLNnm0GH8Eg@xxxxxxxxxxxxxx/ > [2]: https://lore.kernel.org/git/CAPig+cQPUe9REf+wgVNjyak_nk3V361h-48rTFgk6TGC7vJgOA@xxxxxxxxxxxxxx/ Thanks, -Stolee
