From: "Johannes Müller" <dersinndesleb...@gmx.net>
I tried thinking of a way to prevent accidental deletion by git reset
--hard command, as I recently faced such a problem. How can you write
wrapper replacing the command, so that it first does something like
following? It should create a new branch backup with all changes
current_branch = git command
git checkout -b backup_`date`
git add -A && git commit -m "backup before git reset --hard"
git checkout $current_branch
actual git reset --hard command
To me, the "--hard" is a good indicator of a destructive reset.
However the question should be more about why one ends up using a
destructive reset when one either hasn't fully thought through the
options, or perhaps should have used a softer option (and what would it
So the rehetorical question is should it be an alternate option, and how
would it work, to counter the problems of the destructive reset and
trying to protect ourselves from ourselves - Is it a catch 22 problem?
Perhaps there needs to be an extra git env variable
(GIT_RESET_HARD_HEAD) that holds the sha1 of a faked 'commit -A' just
before the 'reset --hard' is performed. This would avoid leaving lots of
dummy/waste branches around. The variable name can be modelled on the
various other FETCH_HEAD MERGE_HEAD and various others).
So have a think about broader options...
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.