Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs

[Jeff King <peff@peff.net>]

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