On Mon, Jul 6, 2015 at 3:40 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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? Having never used contrib/get-new-workdir, and not being involved in the choice, nor recall seeing justification for disallowing the a branch to be checked out in multiple locations, I lack insight to answer. I do recall Mark pointing out that this restriction posed a barrier for his migration from git-new-workdir to "git checkout --to"[1], and Duy adding --ignore-other-worktrees in response. Mark presented a use-case here [2], but then the discussion petered out. I likewise probably lack understanding of the finer points to make a cogent argument for or against. [1]: http://thread.gmane.org/gmane.comp.version-control.git/260387/focus=260411 [2]: http://article.gmane.org/gmane.comp.version-control.git/260645 -- 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