On Wed, Oct 5, 2011 at 7:49 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. If you have the same branch in two workdirs, then if you commit to that branch in one workdir, you have to reset --hard in the other. In that case, wouldn't it make more sense to just use a detached head in the second workdir? $ git checkout topic fatal: branch 'topic' is currently checked out in '...' $ git checkout topic^0 ... topic is updated elsewhere ... $ git reset --hard topic Either way you need to use reset --hard if topic is updated outside of the current workdir, but at least if git encourages you to detach first, you don't accidentally undo a commit. Also, if we wait till commit time to tell the user "sorry, topic's been updated elsewhere", now the user is in a perilous state. They have uncommitted work which they clearly want on topic. And they have to think about what steps are needed to get it there. So, I really don't think this is quite analogous to detached HEAD, nor pushing into a repo's checked out branch. In both those cases, at least the user's work is already committed. Better to prevent checking out the same branch in multiple workdirs with an override for users that want risk shooting their foot off. j. -- 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