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

Eric Sunshine [off-list ref] 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?

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

Eric Sunshine [off-list ref] writes:

quoted

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

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.

On 07/06/2015 03:40 PM, Junio C Hamano 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? 

The only issue I have with git-new-workdir is that git-gc in one 
worktree is unaware of what is in use in another so can prune things 
away. The linked worktrees here nicely solve that problem.

The main use I have of maintaining multiple checkouts of one branch is 
for testing / analysis (where said tests can take days to weeks to run). 
Disallowing use of git's normal mechanism of tracking what is checked 
out in each such tree forces use of another system to do so, just 
imposing different difficulties for this use case. I note that 1) code 
must be ADDED to git to prevent such duplicate checkouts which otherwise 
cause no difficulty to git itself, and 2) adding those checks requires 
additional work to avoid the fallout. I have yet to hear what the upside 
of such a restriction is, I only see downsides.

Mark