From: Nguyen Thai Ngoc Duy Date: Thu, 06 Oct 2011 02:06:25 GMT Subject: Re: [RFC/PATCH] Add multiple workdir support to branch/checkout Message-ID: In-Reply-To: <7vwrcj3sow.fsf@alter.siamese.dyndns.org> On Thu, Oct 6, 2011 at 10:49 AM, Junio C Hamano wrote: > Nguyen Thai Ngoc Duy writes: > >> On Thu, Oct 6, 2011 at 9:56 AM, Junio C Hamano 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