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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]