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

[Andreas Ericsson <ae@op5.se>]

Jeff King wrote:
> On Fri, Jun 13, 2008 at 06:26:28AM +0200, Andreas Ericsson wrote:
> 
>> Why are branches better and more appropriate?
>> Is it because the developer who first thought of stashes didn't think they'd
>> be used for any halflong period of time?
>> Is it because there are actions you can do on a branch that you can't do on
>> a stash?
>>
>> Who's to say what's appropriate and not? If I explicitly tell a system to
>> save something for me I damn well expect it to be around when I ask that
>> same system to load it for me too.
> 
> I think we are getting into circular reasoning here (on both sides):
> 
> Branches are better, because they don't expire. Stashes expire, because
> branches are a better way to do what you want.
> 
> Stashes shouldn't expire, because the user told the stash to save
> information. The user considers it a "save" because stashes hold things
> forever. Stashes hold things forever because they shouldn't expire.
> 
> In other words, yes, the developer who thought of stashes didn't think
> they'd be used for a long period of time. That's _why_ they were
> designed as they were. The status quo argument says "this is what a
> stash is, because that is how it is implemented."
> 
> So I would expect people in favor of the change to say "here is why
> long-term stashes are useful." And I would expect such an argument to
> address the fact that we don't simply want to recreate branches (badly).
> In other words, what is the compelling use case that makes people want
> to stash for months at a time?
> 

Ah right. Thanks for clarifying and putting me back on a useful track.

To me, long-living stashes are useful because I can all of a sudden be
pulled away from something I'm working on and set to work on something
entirely different for up to 6 months (so far we haven't had a single
emergency project run longer than that). It doesn't happen a lot, but
it *does* happen.

When that happens, I just leave everything as-is, because that's the
most useful state for me to find it in and serves as a nice bump to jog
my memory as to precisely it was I was working on. When I get back it's
possible that someone else has committed design changes or some minor
bugfixes, so naturally I always fetch to make sure I inspect the latest
changes.

I sometimes have stashes around for a day or two if it turns out I
absolutely have to fix some bug or add something to an API before I
can finish the feature I just started working on and the minor change
turns out to be not-so-minor (or if it requires a day or two of testing
to verify).

Sure, I could probably benefit from starting a topic-branch immediately
and then rebase it later, but I also have a git-daemon running so my
co-workers can fetch the latest from me (I work with back-end stuff
usually, and sometimes they need mockups of soon-to-be-real API stuff
which we'd prefer not to get into the central repository), and I don't
want them to get the stuff I *know* is incomplete. It leads to confusion
and unnecessary work. Stashes are handy there.

This workflow works fine for me, but I'd be appalled if I all of a sudden
got back from a period of being away, did a git-fetch and had git-gc
remove my stash(es). I rarely have more than one or two.

Come to think of it, I think it has actually happened once, and I spent
two days trying to find the changes I knew I had made before I gave up
and wrote it down to the changes having been done on a testing system
and overwritten at a later time.

I think these are the options we're faced with:
1. Never expire stashes (don't shoot the user)
2. Don't treat stashes specially (shoot the user)
3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)
4. Make the behaviour configurable (let the users shoot themselves)
5. Double the expiration time on stashes and warn for them when they should
   normally have expired (during gc, that is) (shoot the user, but warn first).

I'm all for #4 and will cook up a patch for that next week when I'm on
vacation unless #1 gets applied before that.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231