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

From: Jeff King <peff@peff.net>
Date: Jun 13, 2008, 17:30 UTC
Message-ID: <20080613173041.GA7974@sigill.intra.peff.net>
In-Reply-To: <GL75k5fYVorDQQh654Db9qgZ3DAr5EfRqLBwQe-VpacRGGbsy3c7WA@cipher.nrlssc.navy.mil>

On Fri, Jun 13, 2008 at 11:43:42AM -0500, Brandon Casey wrote:

Show 6 quoted lines

> > 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. ;)

Show 6 quoted lines

> 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