Re: [PATCH v3 23/23] checkout: retire --ignore-other-worktrees in favor of --force

On Tue, Jul 7, 2015 at 4:24 AM, Eric Sunshine [off-list ref] wrote:

On Mon, Jul 6, 2015 at 3:40 PM, Junio C Hamano [off-list ref] wrote:

quoted

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.