On Thu, Oct 6, 2011 at 9:56 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > >> On Thu, Oct 6, 2011 at 5:19 AM, Junio C Hamano <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html