Kevin Daudt <me <at> ikke.info> writes:
>If people execute git checkout . as a habbit
>without thinking, they will soon train to do git checkout -f . without
>thinking, and then you still have the same problem.
I don't quite agree; you only learn to use the -f flag if the plain command
doesn't do what you want. With rm, I want to remove that file, dammit! The
-f flag is often a necessity to stop the tool getting in my way. But when
fixing up a working tree, I rarely want to silently trash any local changes.
>I do share your sentiment that it's easy to loose uncomitted changes to
>git checkout <path>, but like Jeff said, the entire goal of this command
>is to reset specific files from the index or commits.
Well that's not quite the flavour given by the documentation, which says
>Updates files in the working tree to match...
'Updating' files sounds like a fairly safe thing to do, right? Like 'cvs
update' or 'svn update', which don't just overwrite working tree changes.
The doc doesn't really make clear that any local changes will be discarded;
indeed the only mention of that is
-f, --force
When switching branches... this is used to throw away local changes.
To the casual reader, following 'the exception proves the rule', it appears
that local changes are not thrown away except in this case.
--
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