Brandon Casey <casey@xxxxxxxxxxxxxxx> writes: > The fact that this caveat is not mentioned anywhere in the stash > documentation or anywhere in the commit log related to git-stash.sh makes > me think that this idea of 'a limited amount of time' was possibly not a > design decision but merely a side effect of stashes being implemented using the > reflog. Of course I didn't pay any attention to the discussions about stash > back when it was implemented, so I may definitely be wrong. I do not deeply care either way, but perhaps http://thread.gmane.org/gmane.comp.version-control.git/50737/focus=50863 and yes use of reflog was more or less conscious thing and the mechanism is very much temporary in nature (see the use case stated in the starting thread). > it were true that if I were to create a stash today, and then be surprised 30 > days from now when I do a 'stash list' and find the stash is still there. > Something along the lines of: > > $ git stash save my work > # wait 30 days > $ git stash list > stash@{0}: WIP on master: my work > > # and if my reaction were something like: > # hmm, that's strange, what is that stash still doing there? It's been 30 days, > # it should be gone. We could prune before running "git stash list", but why bother? The fact you can see it is like a bonus. -- 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
