Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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'). Correct. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html