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

From: Rogan Dawes <lists@dawes.za.net>
Date: Jun 24, 2008, 12:19 UTC
Message-ID: <4860E63B.6040709@dawes.za.net>
In-Reply-To: <28156.2147582465$1214307807@news.gmane.org>

David Jeske wrote:

Show 12 quoted lines

> -- 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