Re: why is git destructive by default? (i suggest it not be!)
- From
- Rogan Dawes <lists@dawes.za.net>
- Date
- Jun 24, 2008, 12:46 UTC
- Message-ID
- <4860ECC1.9020608@dawes.za.net>
- In-Reply-To
- <20080624123527.GA6149@dualtron.vpn.rwth-aachen.de>
Johannes Gilger wrote:
Show 22 quoted lines
> 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