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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html