# Should 'git reset --hard' keep a stashed backup? 2 messages from 2014-03-16 to 2014-03-16. Participants: Philip Oakley, Duy Nguyen. Thread: https://gitlist.dev/t/36190 ## Philip Oakley, 2014-03-16 21:22 Subject: Should 'git reset --hard' keep a stashed backup? Message-ID: URL: https://gitlist.dev/e/EF7B8A31C59946F8821697F3BA129043%40PhilipOakley ``` A bike-shedding thought: Many inexperienced users do a 'git reset --hard' only to discover they have deleted something important and want it back. (e.g. git-users yesterday [1]) One possible option is that Git could "stash" the current work-tree contents (git stash create) into a commit and store its commit_id in a suitable file/variable such as RESET_HARD_HEAD (or GIT_RESET_HARD_HEAD), similar to FETCH_HEAD & MERGE_HEAD, so that it would be relatively easy to recover the prior state. By only storing the id in the file/env it would be overwritten on each usage, and the loose commits would be garbage collected eventually. A suitable config variable would allow it to be enabled/disabled as appropriate to the user. (Perhaps enabled by default eventually?) Given the prevalence of 'git reset --hard' within internet forum advice, would something like this be useful? It could even be wrapped into a GSoC project. -- Philip [1] https://groups.google.com/forum/#!topic/git-users/CwQyfwnzCVM ``` ## Duy Nguyen, 2014-03-16 23:14 Subject: Re: Should 'git reset --hard' keep a stashed backup? Message-ID: URL: https://gitlist.dev/e/CACsJy8CGvwEk4whaiEn5ccTyRKD4ZwUXqYVM9hTGfU7tYUdX%3DA%40mail.gmail.com In-Reply-To: ``` On Mon, Mar 17, 2014 at 5:17 AM, Philip Oakley wrote: > A bike-shedding thought: > Many inexperienced users do a 'git reset --hard' only to discover they have > deleted something important and want it back. (e.g. git-users yesterday [1]) > > One possible option is that Git could "stash" the current work-tree contents > (git stash create) into a commit and store its commit_id in a suitable > file/variable such as RESET_HARD_HEAD (or GIT_RESET_HARD_HEAD), similar to > FETCH_HEAD & MERGE_HEAD, so that it would be relatively easy to recover the > prior state. A while back I started to implement "undo" function for "git add". I think we could do the same here, when reset --hard is issued, store current SHA-1 in index to an index extension, also hash overwritten files in worktree and store it in the index extension as well. "reset --undo" can bring it back. Experienced user can turn this off via config variable, but it's default to on. > > By only storing the id in the file/env it would be overwritten on each > usage, and the loose commits would be garbage collected eventually. We have similar ideas, except I choose to store in the index instead. > > A suitable config variable would allow it to be enabled/disabled as > appropriate to the user. (Perhaps enabled by default eventually?) Yes. We could even bundle it to an advice.* knob. Experienced users will usually turn the advice off (and this behavior will be gone as the result). > Given the prevalence of 'git reset --hard' within internet forum advice, > would something like this be useful? It could even be wrapped into a GSoC > project. We could go further to provide "git undo" interface that covers other areas as well, easier to discover than "reset --undo", but I'm not sure how this interface should work.. -- Duy ```