Duy Nguyen <pclo...@gmail.com> writes: > I believe the main selling point of multiple worktrees is sharing > refs. You could easily avoid expensive clones with --local, but > synchronizing between different clones is not very convenient. Other > than that, different worktrees tend to behave like separate clones.
OK. Even with the enforced limitation that no single branch can be checked out in multiple worktrees at the same time, it is more convenient as you can "merge" other branch and trust that the result on the checked-out branch in your worktree is immediately visible to other worktrees. > user has multiple worktrees, but the extension is not enabled. I'm Exactly. "config --worktree" in your script will silently break other worktrees; it wanted to affect only the current worktree, but it changed settings to all the others. > probably not clear in the commit message, but "git config" can detect > that the extension has not been enabled, automatically enable it (and > move core.bare and core.worktree (if present) to the main worktree's > private config), so "git config --worktree" will never share the > change. I wonder if that is good enough. The user in one worktree did "config --worktree" and all the worktrees now start diverging in their config---but that is true _only_ when they use "--worktree" option to say "I want this to be set differently from others". All the other calls to "git config" will stil be shared. So from a cursory thinking, it sounds OK to me, but somebody else may think of bad ramifications after a good night sleep.
