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 <sxe...@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 <pclo...@gmail.com> wrote: >> >> On Tue, Nov 27, 2018 at 5:53 PM Nguyễn Thái Ngọc Duy <pclo...@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
