[git-users] test
test -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Undoable reset hard
Hi, 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 a wrapper replacing the command, so that it first does something like the following? It should create a new branch backup with all changes before resetting. 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 Thx, Johannes -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Undoable reset hard
From: "Johannes Müller" Hi, 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 a wrapper replacing the command, so that it first does something like the following? It should create a new branch backup with all changes before resetting. 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 Thx, Johannes 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 be). 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... Philip -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] git send-email missing dependency?
Hello everyone, I've tried to use git send-email to send my patch but it seems that there is a missing perl dependency? Anyway I've attached my patch and send it via gmail. -- 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 to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
