On Wed, Dec 29, 2021 at 9:31 AM Derrick Stolee <stolee@xxxxxxxxx> wrote: > > On 12/29/2021 1:37 AM, Eric Sunshine wrote: > > On Tue, Dec 28, 2021 at 4:32 PM Derrick Stolee via GitGitGadget > > <gitgitgadget@xxxxxxxxx> wrote: > > The obvious way to work around this problem is to (again) special-case > > `core.bare` and `core.worktree` to remove them when copying the > > worktree-specific configuration. Whether or not that is the best > > solution or even desirable is a different question. (I haven't thought > > it through enough to have an opinion.) > > It makes sense to special case these two settings since we want to > allow creating a working worktree from a bare repo, even if it has > worktree config stating that it is bare. Agreed. > As far as the implementation goes, we could do the copy and then > unset those two values in the new file. That's an easy enough change. > I'll wait for more feedback on the overall ideas (and names of things > like the init-worktree-config subcommand). What value does the init-worktree-config subcommand provide; why shouldn't we just get rid of it? I know Eric was strongly suggesting it, but he was thinking in terms of always doing that full switchover step, or never doing it. Both extremes had the potential to cause user-visible bugs, and thus he suggested providing a command to allow users to pick their poison. I provided a suggestion avoiding both extremes that doesn't have that pick-your-poison approach, so I don't see why forcing users into this extra step makes any sense. But perhaps I missed something. Is there a usecase for users to explicitly use this?
