Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > As a safeguard, checking out a branch already checked out by a different > worktree is disallowed. This behavior can be overridden with > --ignore-other-worktrees, however, this option is neither obvious nor > particularly discoverable. As a common safeguard override, --force is > more likely to come to mind. Therefore, overload it to also suppress the > check for a branch already checked out elsewhere. I hate to be asking this again but why is it a good idea to allow 'ignore-other-worktrees' in the first place (let alone making it more discoverable)? You'll have multiple working trees, either using the new "git worktree" or using the old contrib/workdir, for one of the two reasons: * You need a separate work area to build a new history. * You need a separate work area to expand the contents of a specific commit. Here "create binary by running make" falls into the latter category; as far as Git is concerned, you are only looking at, not extending the history of any specific branch. If you are extending the history of some branch, then you would want to be on that branch. Why would you want to have another worktree that will get into a confusing state once you create that commit on the checked out branch in this newly created worktree? Wasn't the whole point of making the primary repository aware of the secondary worktrees via the "linked checkout" mechanism because that confusion was the biggest sore point of the old contrib/workdir implementation? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html