Thank you for your feedback.
I suppose that turning a hypothetical confirmation option 'on' would
impact a stash pop for instance as it automatically drops the stash if
it was applied without conflicts.
What about a --confirm flag? You could then simply alias 'git stash
drop --confirm' locally and it wouldn't impact anything else?
Have a great week-end!
On 29 June 2017 at 20:56, Stefan Beller <sbel...@google.com> wrote:
> On Thu, Jun 29, 2017 at 11:44 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> Laurent Humblet <laurent.humb...@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.
