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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
