I had expected that 'git checkout .' would fix up my working tree to make it
match the repository (in this case, the current revision of the master
branch). When I originally ran it I had deleted a couple of files from the
working tree and wanted to restore them. However, I expected that if doing
the checkout operation would lose data currently on disk then git would
prompt me first.
To compare, 'git pull' will not silently overwrite local changes; it will
prompt you to commit or stash them first. 'git checkout .' is a fairly
innocuous-looking command; it doesn't contain any --force or --overwrite or
other things that would make you think twice before typing it. So I suggest
it should be equally safe to run.
The user interface might be something like:
% git checkout .
error: Your local changes to the following files would be overwritten:
foo
You may want to commit or stash these changes, or delete the files if you
don't want them. Use 'git checkout --force' to proceed, throwing away
local changes.
Aborting
If the checkout operation would only involve creating some files on disk
which aren't currently there, then it would proceed without prompting.
--
Ed Avis <eda@xxxxxxxxxxxxx>
--
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