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

Johannes Gilger wrote:

On 24/06/08 14:19, Rogan Dawes wrote:

quoted

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.

I think the name of the command "reset" itself is a name which should 
prompt everyone to read a manpage before using it. I could understand 
that if "status" did something destructive people would get upset.
Other than that, git reset itself doesn't do anything destructive. Yeah, 
git reset --hard does, but hello, this is *reset* and *hard*, someone 
using this must really want what's about to happen. Nobody complaines 
about rm --force or anything.

As for putting safety-measure everywhere, I think that any further 
restricting of commands would be nonsense and just hindering the 
workflow. git is not something with a GUI and a recycle-bin. And it 
still is really hard to accidentaly lose anything in git.

Regards,
Jojo

Right. I was simply pointing out to the original poster that for all the 
talk about reflogs, if you use "reset --hard", all bets are off. I was 
not complaining about the existence of that option, or its name . . .

I agree that adding nanny-guards to git would be counter productive.

Rogan