David Jeske wrote:
-- Jakub Narebski wrote:
If they are using '-f', i.e. force, they should know and be sure what
they are doing; it is not much different from 'rm -f *'.
Sure, no problem. I don't want the ability to "rm -f *". I'm raising my hand
and saying "I don't want the power to do these things, so just turn off all the
git commands that could be destructive and give me an alternate way to do the
workflows I need to do". Just like a normal user on a unix machine doesn't run
around with the power to rm -f /etc all the time, even though they may be able
to su to root.
Let me guess, you're always running euid==0. :)
Do you also ask the gnu coreutils folks to remove the -f option from
their utilities?
There is a basic assumption that folks that are using tools have at
least made an attempt to understand what it is that they are doing,
before e.g. waving a chainsaw around.
One thing that I haven't seen addressed in this thread is the fact that
if you have a dirty working directory, and you "git reset --hard",
whatever was dirty (not yet in the index, or committed) will be blown
away, and no amount of reflog archeology will help you get it back.
Any changes that had been staged in the index WILL exist in the object
directories as dangling objects, and can be retrieved through judicious
use of "git fsck" and "git show", but will certainly be a painful
exercise if there was an extensive set of changes.
Rogan
--
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
