On Tue, Jul 7, 2015 at 4:24 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Mon, Jul 6, 2015 at 3:40 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> 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? > > I [...] probably lack understanding of the finer points to make a > cogent argument for or against. Is receive.denyCurrentBranch worth mentioning as an argument? Although pushing a branch into a non-bare repo where that branch is already checked out is normally disallowed, receive.denyCurrentBranch overrides the safeguard. Presumably, the user has experience and knowledge to know that "git reset --hard" will be required to sync things up. Using --force or --ignore-other-worktrees (or whatever) to override git-checkout's normal safeguard against checking out a branch into more than one linked-worktree parallels receive.denyCurrentBranch, doesn't it? There is a certain amount of precedent elsewhere in Git for allowing a person to shoot himself in the foot. -- 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