Re: [PATCH/RFC v2 0/7] Introduce new commands switch-branch and checkout-files

[Stefan Xenos <sxenos@google.com>]

I think users have problems with detached heads for several reasons:

1. Users often enter the detached head state unexpectedly (for
example, by mistyping a "checkout" command or not understanding its
multipurpose nature, or as a side-effect of running a submodule
command). The change described here will go in the right direction
towards addressing this, since you won't be able to accidentally
detach your head by mistyping checkout. If detaching was always an
intentional action by the user, it would be much less intimidating.

2. Git shows a lot of scary error messages when running in a detached
head state. They tell you you're doing something dangerous, which
dissuades users from experimenting with the feature. IMO, it would be
better to replace the scary warning messages with instructions on
where to get more information about detached heads (and those
instructions should frontload info on how to reattach to a branch and
how to recover commits from the reflog).

3. When in a detached head state, a lot of commands add extra
confirmation prompts, which are unnecessary and intimidating.

Basically, the current user interface implies to the user that a
detached head is an error condition they'll need to recover from
rather than the normal and useful mode of working that it is.

(I'm resending this email without html - sorry if you received it twice).

So - IMO - detaching should always be an explicit action. Some options
that occur to me:

git switch-branch --detach
git detach
git switch-branch HEAD

  - Stefan

On Wed, Nov 28, 2018 at 2:48 PM Stefan Xenos <sxenos@google.com> wrote:
>
> I think users have problems with detached heads for several reasons:
>
> 1. Users often enter the detached head state unexpectedly (for example, by mistyping a "checkout" command or not understanding its multipurpose nature, or as a side-effect of running a submodule command). The change described here will go in the right direction towards addressing this, since you won't be able to accidentally detach your head by mistyping checkout. If detaching was always an intentional action by the user, it would be much less intimidating.
>
> 2. Git shows a lot of scary error messages when running in a detached head state. They tell you you're doing something dangerous, which dissuades users from experimenting with the feature. IMO, it would be better to replace the scary warning messages with instructions on where to get more information about detached heads (and those instructions should frontload info on how to reattach to a branch and how to recover commits from the reflog).
>
> 3. When in a detached head state, a lot of commands add extra confirmation prompts, which are unnecessary and intimidating.
>
> Basically, the current user interface implies to the user that a detached head is an error condition they'll need to recover from rather than the normal and useful mode of working that it is.
>
>   - Stefan
>
> On Wed, Nov 28, 2018 at 12:01 PM Duy Nguyen <pclouds@gmail.com> wrote:
>>
>> On Tue, Nov 27, 2018 at 5:53 PM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
>> >
>> > v2 is just a bit better to look at than v1. This is by no means final.
>> > If you think the command name is bad, the default behavior should
>> > change, or something else, speak up. It's still very "RFC".
>> >
>> > v2 breaks down the giant patch in v1 and starts adding some changes in
>> > these new commands:
>> >
>> > - restore-paths is renamed to checkout-paths. I wrote I didn't like
>> >   "checkout" because of completion conflict. But who am I kidding,
>> >   I'll use aliases anyway. "-files" instead of "-paths" because we
>> >   already have ls-files.
>> > - both commands will not accept no arguments. There is no "git
>> >   checkout" equivalent.
>> > - ambiguation rules are now aware that "switch-branch" for example
>> >   can't take pathspec...
>>
>> Another thing. Since we start with a clean slate, should we do
>> something about detached HEAD in this switch-branch command (or
>> whatever its name will be)?
>>
>> This is usually a confusing concept to new users and I've seen some
>> users have a hard time getting out of it. I'm too comfortable with
>> detached HEAD to see this from new user's perspective and a better way
>> to deal with it.
>> --
>> Duy