On Thu, Jun 29, 2017 at 11:44 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Laurent Humblet <laurent.humblet@xxxxxxxxx> writes:
>
>> Would it be possible to add an optional Yes/No when doing a 'git stash
>> drop'? Something similar as what happens when pushing on a remotely
>> checked out branch (with a config setting to turn the warning on/off).
>>
>> I know that you can always get your dropped stash back using git
>> reflog but a small warning might be a useful feature to avoid unwanted
>> stash drops on a regular basis.
>
> I sympathize with this, but the same principle also would apply many
> destructive commands like "git reset --hard", "git rm <path>", etc.
> and also "/bin/rm -f" ;-)
>
> I however do not think a good general way to do this without
> breaking people's scripts. When they do 'stash drop' in their
> scripts, they know they want to get rid of the dropped stash
> entries, and they expect that the user may not necessarily be
> sitting in front of the shell to give the command a Yes (they
> probably wouldn't even give the user a message "the next step
> may ask you to say Yes; please do so").
>
> On the other hand, just like "git reset --hard" and "git clean -f"
> does not have such safety (i.e. the user is aware that the command
> is destructive by giving "--hard" and "-f"), "drop" may be a sign
> that the user knowingly doing something destructive.
>
> So I dunno.
>
I was about to propose to have an easy undo operation, such as the
reflog. But then I checked the man page for git-stash and it already says:
older stashes are found in the reflog of this reference and can be named
using the usual reflog syntax (e.g. stash@{0} is the most recently
created stash, stash@{1} is the one before it, stash@{2.hours.ago} is
also possible). Stashes may also be referenced by specifying
just the stash
index (e.g. the integer n is equivalent to stash@{n})
Maybe that needs to be polished a bit more?
I myself used the stash back then (I don't use it any more), and I assumed
the stash was a stack of changes, but the data structure seems to imply it
is only one thing that can be stashed and the reflog enables the stacking
part, such that a dropped stash is gone and is not recorded in the reflog.
Dropping a stash seems to just erase the topmost line from the stash reflog,
so it really is as destructive an "/bin/rm -f"
So getting back a dropped stash via the reflog is not via asking for a stash
reflog but rather for HEADs or a branchs reflog, which may be complicated.
