Re: [git-users] Undoable reset hard
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 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 That seems to be the normal way things like this are done in Git. But usually, the backup branch seems to be put in refs/original/full_ref_name_of_branch, e.g., refs/original/refs/heads/master. Dale -- 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
Hi, I can answer the question to why I ended up using reset at least, though I can imagine more scenarios. I wanted to do a reset on the current working directory (read subdirectory of the repository) instead of on the whole repository, and assumed git would do as I intuitively expected it to, without specifying the path. I should have stopped to think about this, and look up the behavior in the docs, but since I was concerned with other things I simply didn't. Actually, I still think it would be more intuitive to let git act upon the current working directory if none is specified, to prevent harm. Nonetheless, I would be happy with the proposed wrapper, but need some help to realize it. It is not that this is a need to have feature, since I normally commit most of the stuff in my working directory regularly. But it would be nice to have. Thx, Johannes On 16.03.2014 00:56, Philip Oakley wrote: 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.
Re: [git-users] Undoable reset hard
While reading your explanation I've imagined Bart Simpson writing Git is always working on the whole index over and over on the desk:) Sorry. On Sun, Mar 16, 2014 at 2:35 PM, Johannes Müller dersinndesleb...@gmx.net wrote: Hi, I can answer the question to why I ended up using reset at least, though I can imagine more scenarios. I wanted to do a reset on the current working directory (read subdirectory of the repository) instead of on the whole repository, and assumed git would do as I intuitively expected it to, without specifying the path. I should have stopped to think about this, and look up the behavior in the docs, but since I was concerned with other things I simply didn't. Actually, I still think it would be more intuitive to let git act upon the current working directory if none is specified, to prevent harm. Nonetheless, I would be happy with the proposed wrapper, but need some help to realize it. It is not that this is a need to have feature, since I normally commit most of the stuff in my working directory regularly. But it would be nice to have. Thx, Johannes On 16.03.2014 00:56, Philip Oakley wrote: 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. -- Serge Matveenko mailto: se...@matveenko.ru github: http://lnkfy.com/1 linkedin: http://lnkfy.com/S Пародуй.рф — http://www.parodui.ru/ Специализированный магазин электронных сигарет СПб, Ленинский проспект 79 корп. 3, +7 (812) 951-25-24 -- 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 dersinndesleb...@gmx.net 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.
