Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > On Thu, Oct 6, 2011 at 9:56 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> I think of two options: >>> ... >> 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". I see what you mean, but doesn't it feel as if it is working around a problem that is introduced only because of a wrong policy (i.e. "you cannot check out the same branch at two places", as opposed to "viewing them in multiple places is perfectly fine, but no touching")? This reminds me of how we ended up handling the "scary warning" around detached HEAD. It is not wrong nor even dangerous to detach. It is not wrong nor even dangerous to make commits on detached HEAD. It is however dangerous to switch away from that state without saving it to a ref, and that is where we give warnings. -- 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