On Wed, Oct 5, 2011 at 8:43 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Not at all. My build infrastructure determines where to install the built > binary based on what branch is checked out. Having a head detached at a > commit that is at the tip of one branch is not necessarily the same as > having the branch actually checked out. That's fair, but I'm willing to wager that's a minority use-case. Not that it shouldn't be possible, but perhaps it should require telling git that's really what you want to do with checkout --force. >> 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. > > Wouldn't the "elsewhere" user would be warned before being able to update > the branch? I thought the whole point of your adding "this branch is > checked out over there" is exactly so that the "elsewhere" user can come > talk to you before that happens. These two people might be yourself, of > course. So you're envisioning this? $ git commit foo.c Warning, master is also checked out in workdir2 How does that help the user? Now they have to go to workdir2 and reset --hard. Is that really something we want to encourage? And what if they do this: $ cd workdir1 $ edit foo.c ... time passes... $ cd workdir2 $ edit foo.c $ git commit foo.c Warning, master is also checked out in workdir1 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