Re: Bug: git stash store can create stash entries that can't be dropped

From: Erik Cervin Edin <erik@cervined.in>
Date: Oct 11, 2023, 19:44 UTC
Message-ID: <CA+JQ7M9j5_1kJ2+E70+EXF6wFyPPovHnz=T26sQ2hOr0cyaO8g@mail.gmail.com>
In-Reply-To: <xmqqzg0pnmv5.fsf@gitster.g>

On Wed, Oct 11, 2023 at 6:29 PM Junio C Hamano <gitster@pobox.com> wrote:

> I am of two minds.  As "stash store" and "stash create" were
> invented as, and have always been ever since, pretty much
> implementation details of scripted "stash save", the user deserves
> what they get when they abuse them: garbage-in, garbage-out.

Fair. I knew what I was doing was probably not kosher. Still, the documentation says

           git stash store [(-m | --message) <message>] [-q | --quiet] <commit>

and then later clarifying

           Store a given stash created via git stash create (which is
a dangling merge commit) in the stash ref, updating the stash reflog.
This is intended to be useful for scripts.
           It is probably not the command you want to use; see "push" above.

I knew git stash store is meant to be used with git stash create. But I didn't expect to be able to create a stash entry that I wouldn't be able to drop.

Show 6 quoted lines

> Yes, this is exactly what the user deserves.
>
> Having said that, I agree that this shows an uneven UI.  The "drop"
> command cares about what it is dropping and refuses if it is not a
> stash-like thing, so it is understandable to wish "store" to also
> care to the same degree.

I can see why I deserve the mess I made for myself. But I'm also inclined to think that if I've been allowed to make said mess, I should similarly be allowed to clean it up, without having to manually delete the entry from the stash reflog. (In case someone else finds themselves in a similar mess, I just went into the .git/logs/refs/stash and deleted line of the offending stash entry)

I think a more user-friendly behavior is to either prevent the user from making the mess, or not prevent the user from cleaning it up. Doing both seems a tad overzealous. Hard for me to say which is better. For example, it's not immediately clear, to me, why git stash drop cares about the validity of stash entries to be dropped. But maybe there are edge cases where it's good to be defensive here.