Re: Suggestion: make git checkout safer

Maybe the expectation comes from the existing warnings when checking out branches?

    $ mkdir tmp && cd tmp
    $ git init
    $ echo Hello >foo
    $ git add foo
    $ git commit -am "Hello"
    $ git branch next
    $ echo "world" >bar
    $ git add bar
    $ git commit -a -m "World"
    $ git checkout test
      # no problem so far, just going back one commit on anther branch
    $ echo Kitty >bar
    $ git checkout master # now we get it:
    error: The following untracked working tree files would be
overwritten by checkout:
    bar
    Please move or remove them before you can switch branches.
    Aborting

So in one mode, we do actually warn about contents going missing, and the other mode is designed to actually make things go missing without any warning.

So maybe the checkout command is *too powerful* ? Looking at the man page:

    Updates files in the working tree to match the version in the index or the
    specified tree. If no paths are given, git checkout will also update HEAD
    to set the specified branch as the current branch.

we're mixing two different tasks here anyway. "Updating files in the work tree" can be understood as "throwing away all changes until you're back at a specified safe point". If I were to come up with a name for such an action it's maybe "reset" or "reset-file(s)". Though git reset is taken already and does different things. "reset" sounds as if stuff may go missing, so anyone who types "reset", (even without exactly understanding what it does, would assume it is as safe as typing "rm" probably.

 And "also update HEAD" can be understood as "switch to another branch",
so if I were to invent a new porcelain command for such functionality it may be
called "git switch-branch". And typing switch-branch would be expected
to carry all
the warnings (no updating files in the work tree, when in danger of
losing its content)