git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Should 'git reset --hard' keep a stashed backup?

From
Philip Oakley <philipoakley@iee.org>
Date
Mar 16, 2014, 21:22 UTC
Message-ID
<EF7B8A31C59946F8821697F3BA129043@PhilipOakley>

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 
Next: Duy Nguyen
Message 1 of 2 in “Should 'git reset --hard' keep a stashed backup?”
  1. Philip OakleyMar 16, 2014
  2. Duy NguyenMar 16, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.