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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jul 7, 2015, 09:41 UTC
Message-ID: <CAPig+cSz3xS-pdtsiw14A80m7UqdwfGLy6kRdguHSUyAjfnWSQ@mail.gmail.com>
In-Reply-To: <CAPig+cSSooqUcR_gW6vQP5Ws5v9p47bt7JWX4HgAyD6mFZynDA@mail.gmail.com>

On Tue, Jul 7, 2015 at 4:24 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:

Show 13 quoted lines

> On Mon, Jul 6, 2015 at 3:40 PM, Junio C Hamano <gitster@pobox.com> 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.