Re: Warning suggestion for git stash drop

From: Stefan Beller <sbeller@google.com>
Date: Jun 29, 2017, 18:56 UTC
Message-ID: <CAGZ79kYd+3OoUBcsTS9=S9qEUwKj9ypyHyjXLBW=KjWOVoae4A@mail.gmail.com>
In-Reply-To: <xmqqefu2tyzc.fsf@gitster.mtv.corp.google.com>

On Thu, Jun 29, 2017 at 11:44 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 29 quoted lines

> Laurent Humblet <laurent.humblet@gmail.com> 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.