On Fri, Jun 13, 2008 at 11:43:42AM -0500, Brandon Casey wrote: > > No, but it would have to be performed _after_ the expiration, but > > _before_ any auto-gc happened. So it is a smaller window than "anytime > > after expiration" but not as small as a particular 30-second window. > > Right, that's why I showed the 'git-stash list' which still had the > stash entry before the 'git-pull'. Right, but I meant that you would have to perform the example commands you gave after the expiration, but before you had done anything that did an auto-gc. So you could do it at day 31, unless on day 30 you had done a "git pull". But somebody else mentioned that they leave cloned working trees sitting around, and then find them later. So they might truly have done no commands. At any rate, I don't think is especially relevant. > Funny you should mentioned that since I had thought of using a similar > example in defense of my point of view. So I offer a question: after how > much time after you have yanked some text into a register in vi do you > expect vi to clear that register? After 10 other yanks? ;) I was referring not to the named registers, but to the unnamed ones. IOW, I know that vim will keep my registers from session to session. But when I yank, it implicitly goes into "0, and the old "0 bumps to "1, "1 to "2, and so forth. "9 is thrown away. And I think that works pretty well in practice. The size is bounded, but text stays around long enough for me to use it. And if I want storage that is guaranteed to last (and I sometimes do), then I use a named register. Now here we are bounding by time rather than by number of stashes, but it is the same concept. > yanks as being tied to the session. Similarly with something like X11 > when you highlight text, you expect it to be there in the copy buffer > until other text is highlighted or until X terminates. Ah, if only that was how X cut buffers actually worked. ;) > I see it as less of a workflow issue than a safety issue, and a user > interface issue. I don't know if there are workflows that would be > made possible by not expiring the stash. I do think the benefit of > automatically cleaning out the stash so it doesn't accumulate old > cruft is less important to me than an intuitive interface and > predictable behavior. At this point I am inclined to agree. Enough people seem to want to leave things stashed for long periods that it is a potential hazard to people who don't know about the expiration. And while I prefer the expiring cruft behavior, not expiring it isn't _that_ big a deal to me, compared against the potential for loss. -Peff -- 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
