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

[Mark Levedahl <mlevedahl@gmail.com>]

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