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

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

Johannes Gilger wrote:
> On 24/06/08 14:19, Rogan Dawes wrote:
>> 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