Re: [PATCH] checkout: indicate when a detached head is checked out for a branch

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
> > I really like the new --to feature and will convert all my "new workdir"
> > checkouts to that. But that detached checkout is so easy to miss - in fact
> > I noticed it only when I compared "new-workdir" to "checkout --to" for a
> > test repo with one branch, to see what a converter would need to do.
> >
> > I'm even wondering whether we should do this DWIMmery at all, given how
> > "dangerous" a detached head is for those who are not aware of it
> > before gc kicks in.
> 
> As long as the amount of warning about 'detached HEAD' is about the
> same between this case and a "git checkout v1.2.3" in a normal
> repository, I do not think there is no additional "danger" you need
> to be worried about.
> 
> But I do agree that there should not be any DWIM here.
> 
> The reason to introduce this new set of rather intrusive changes is
> so that working trees can be aware of branches other working trees
> have checked out.  And the whole point of wanting to have that
> mutual awareness is to enable us to forbid users from mucking with
> the same branch from two different places.
> 
> But Git is not in the position to dictate which alternative action
> the user would want to take, when her "git checkout foo" is
> prevented by this mechanism.  In one scenario, she may say "I only
> wanted to take a peek" and run "git checkout foo^0" instead.  In
> another, she may say "Ah, I forgot I already was doing this change
> in the other one" and run "cd ../foo".  There may be other classes
> of alternative actions.
> 
> Don't make it easier for the first class of scenario and make it
> less useful and more dangerous for the second class, especially the
> second class involve forgetful users who are likely to forget seeing
> the "we've warned you that we detached without being asked" message.
> 
> Please fix it to always just error out.