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

[Michael J Gruber <git@drmicha.warpmail.net>]

Duy Nguyen venit, vidit, dixit 18.07.2014 12:58:
> On Fri, Jul 18, 2014 at 4:50 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> 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,
> 
> This is what this series needs, user's opinions (bad or good). The
> other option is abort the checkout immediately. I think I made detach
> behavior default is because it's more work (and needs to be proven
> feasible). How about a config key that lets user decide what to do
> here, abort or detach. We may change the default behavior too if
> people think the current one is not good.

Uh, config bloat :)

I think DWIMmery is OK if it's made clear to the user what happened, and
it is somewhat expected/probably intended behavior.

Do we have a precedent where a detached head is produced when a branch
checkout is requested, or something similar? I think checking out remote
tracking branches is somehow in that same boat.

>> given how "dangerous" a detached head is for those who are not aware of it
>> before gc kicks in.
> 
> Wait, what danger are we talking about? I thought gc pays attention to
> detached heads as well..

As long as HEAD points to it, of course.

I think detached head is one of the killer features of git, in both
senses of the meaning...

Don't we DWIM (or suggest) "git checkout origin/master" to "git checkout
--track origin/master" which creates master with upstream origin/master?

Maybe I'm mixing things up, but I think we try to produce detached heads
only on special requests. New users get confused by them, some don't
understand the (well crafted) message you get when you switch away from
them, and while you can recover them from HEAD's reflog, they are gone
with the next gc unless they remain checked out (or get referenced).

I think I've just convinced myself that we shouldn't DWIm to a detached
head, and rather tell the user how to produce one if she really intended
to: "git checkout --detach..." That one seems to be broken by multiple
workdir setup (in the sense of producing an unnecessary hint).

Michael