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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jul 18, 2014, 13:27 UTC
Message-ID: <53C920D6.80104@drmicha.warpmail.net>
In-Reply-To: <CACsJy8CG17tzWWO27Pv2c+CjDyYiYATzgBSFfMBaugYgQfZQ5g@mail.gmail.com>

Duy Nguyen venit, vidit, dixit 18.07.2014 12:58:

Show 15 quoted lines

> 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.

Show 5 quoted lines

>> 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