On Wed, 05 Oct 2011 15:11:30 +0000, Jay Soffian wrote: ... > > - Error out (or warn if forced) upon any attempt to update the tip of a > > branch that is checked out in more than one place; and > > I think that's a worse user experience. "Sorry, can't commit your > changes because you've checked out this branch elsewhere." This is actually pretty much the same as "you can't push into the currently checked-out branch". I do come from CVS where multiple checkouts of the same branch are obviously common, but the semantics are different. git would need to allow to be in a detached state but still have a notion of a 'current' branch to mimic that; this tentative 'current' branch being what we need to merge or rebase onto later. Just thinking. It may actually be logical to put the other workdirs into detached state when the branch they are on is committed into; however, this is seriously confusing. > Now the > user's choices are: > > 1. commit --force (and thus confusing the other workdirs) > 2. checkout -b new_branch && commit > > Both of which I think are worse than preventing the checkout in the first place. Hmm. You mean forcing the user to make a new branch *earlier* than at commit time is better? Andreas -- 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