Eric Sunshine <sunsh...@sunshineco.com> writes: > On Tue, Jun 30, 2015 at 12:56 AM, Eric Sunshine <sunsh...@sunshineco.com> > wrote > Speaking of "git worktree new --force", should we revisit "git > checkout --ignore-other-worktrees" before it gets set in stone? In > particular, I'm wondering if it makes sense to overload git-checkout's > existing --force option to encompass the functionality of > --ignore-other-worktrees as well. I don't think there would be any > semantic conflict by overloading --force, and I do think that --force > is more discoverable and more intuitive.
"git checkout -f" is to throw-away local changes, which is a very sensible thing to do and I can see why that would be useful, but does --ignore-other-worktrees have the same kind of common-ness? It primarily is a safety measure, and if the user wants to jump around freely to different commits in multiple worktrees, a more sensible thing to do so without getting the "nono, you have that branch checked out elsewhere" is to detach HEADs in the non-primary worktrees that may want to have the same commit checked out as the current branch of the primary worktree. I would mildly object to make --ignore-other-worktrees more discoverable and moderately object to make that feature more accessible by overloading it into "--force". I personally would not mind if we removed "--ignore-other-worktrees", but that might be going too far ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
