From: Nguyen Thai Ngoc Duy Date: Wed, 05 Oct 2011 23:11:26 GMT Subject: Re: [RFC/PATCH] Add multiple workdir support to branch/checkout Message-ID: In-Reply-To: <7vaa9f59p5.fsf@alter.siamese.dyndns.org> On Thu, Oct 6, 2011 at 9:56 AM, Junio C Hamano wrote: > Nguyen Thai Ngoc Duy writes: > >> On Thu, Oct 6, 2011 at 5:19 AM, Junio C Hamano wrote: >>> I do not necessarily think that it is a good approach to forbid the same >>> branch to be checked out in two different places, by the way. One reason >>> people would want to keep multiple workdirs is so that while they are >>> still working on a branch and are not yet at a good "stop point" to even >>> make a temporary commit to get interrupted, they find it sometimes >>> necessary to be able to build the tip of that same branch and even make a >>> small in-working-tree fixes (which later will be carried back to the >>> primary branch). The problem arises only when one of the repositories try >>> to update or delete the branch while it is checked out in another working >>> tree. >> >> I think of two options: >> >>  - detach from the already locked branch (pretty much like what we do >> with tags now) >> >>  - refuse normally but let "checkout -f" do it anyway. However the >> checkout lock will remain at the original worktree. If you want to >> update branch from the second checkout, do "commit -f" and take >> responsibility for your action. > > Sorry, what problem are you trying to solve? Does that "checkout -f" meant > to nuke the local changes that are not yet at a good "stop point"? I meant "git checkout" on the already locked branch is refused, but "git checkout -f" in that case will act just like "git checkout" ignoring all locks. But I forgot that "git checkout -f" also discards worktree changes. Maybe "git checkout --ignore-locks" instead of "git checkout -f". -- Duy