On Thu, Oct 6, 2011 at 10:49 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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")? Well, we could do change the default so "git checkout" == "git checkout --ignore-locks". "git commit --ignore-locks" would commit without checking locks. "git commit" could either: - reject because it does not hold the lock (to hostile?) - detach automatically then commit The latter has a benefit that we can now checkout tags without detaching from the beginning. "git branch" would show tag name until you commit. -- 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