Jeff King wrote:
On Fri, Jun 13, 2008 at 09:16:42AM +0200, Andreas Ericsson wrote:
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.
So of course my first question is "then why didn't you use a branch?" :)
Because stashes are convenient, never get propagated anywhere by accident,
are easy to apply, means you won't have the hassle of creating "topic-bugs"
and later merge it into "topic" when you find something you need to fix
before you merge "topic" into "master". There are lots of good reasons.
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 am tempted by #3, which again matches my workflow. But again, it seems
like an accident waiting to happen for unsuspecting users.
So I think either #1 or #4 is reasonable. #4 probably isn't worth the
effort. If the stash reflog gets too cluttered, one can always expire or
clean it manually.
Right. If #1 gets dropped, I'll most likely hack up #4 though. I'd hate
for one part of git to be able to silently drop work when every other
aspect of it makes damn sure that never, ever happens.
I can imagine lots of people complaining if the merge logic suddenly
starts clobbering dirty work-tree files with an mtime 90 days in the past,
even though the user hasn't explicitly asked git to take care of those at
all.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
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
