Ramkumar Ramachandra <artag...@gmail.com> writes:
> 1. Any stash that can be shown can be applied, but not necessarily
> popped or dropped (as the documentation indicates). The reason for
> this is simple: a pop/drop attempts to clear the entry in the stash
> reflog as well, but all stashes need to have a corresponding reflog
> entry (for instance, those created with 'stash create').
To show or apply, you only need a product of "stash create" that may
not be linked anywhere in the refs or reflogs. But you can only pop
or drop something on the stash reflog.
> 2. IS_STASH_LIKE is a misnomer: all it checks is that the given <rev>
> is a merge commit.
The purpose of the logic is to reject a mistake to name stuff that
is clearly not a product of "stash create". The name is just being
humble by not claiming "I know this is definitely a product of
stash-create" but merely hinting "This smells like such an object";
I am not sure if that is a "misnomer".
You are free to try to think of a way to tighten the implemention to
reject a random two-or-three parent merge commit that is not a
product of "stash create". People already have looked at this code
since it was written, and didn't find a reasonable way to tighten it
without triggering false negatives, so I wouldn't be surprised if
anybody tried it again today and failed.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html