Re: why is git destructive by default? (i suggest it not be!)

[Rogan Dawes <lists@dawes.za.net>]

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