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@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
