El 13/6/2008, a las 23:41, Johannes Schindelin escribió:
Hi,
On Fri, 13 Jun 2008, Wincent Colaiuta wrote:
El 13/6/2008, a las 6:52, Johannes Schindelin escribió:
If you need something from the stash a day after stashing it, you
have
a serious problem with understanding what branches are for.
While this may be true for codebases which move forward quickly, what
about one which is basically finished and tends not to get touched
in a
long time. A situation arises, you stash something, the phone
rings, and
for whatever reason the stash gets forgotten and you don't revisit
the
project at all for days, weeks, months. It wouldn't be nice to
eventually come back and discover that your in-progress work had been
"garbage" collected for you.
You cannot be serious about not wanting to lose the changes when you
keep
them in _one_ _single_ repository anyway.
And you cannot be serious about not wanting to lose the changes when
you
forget about them, for months, even.
So you are making my point for me.
Your arguments are _totally_ spurious.
With respect to your first point, I didn't even mention repository
duplication and backups so I don't know why you tried to inject it
into the discussion. I am _completely_ serious about preserving my
data in the repos I work on, and that's why I do automated backups of
the home directory which contains all of my local working repos every
two hours (ie 12 times per day), plus an automated whole-disk backup
once every 24 hours. However, my point about "git stash" is completely
independent of my backup regimen; the backup regimen exists to protect
me against disk and system failures, not to protect me from my SCM.
And on your second point, you are arguing that anything you can't
remember isn't worth keeping, which just isn't a sustainable argument.
Can you remember the thousands of commits in Git's complete history?
Would it be okay to just throw away the changes you've forgotten about?
So I don't think I've made your point for you at all; it remains for
you to make it for yourself. But it seems to me that you are arguing
against the sizeable majority of participants on this thread which has
already dragged on too long.
So, let's recap:
(1) It is reasonable to expect, and in fact it is clear that most
users _do_ expect, that Git should indefinitely remember changes that
they told it to remember with "git stash save"
(2) The people largely responsible for the implementation of "git
stash" never envisaged its use for long term storage (either
intentional abuse of "stash", or inadvertent misuse) and architected
it in such a way that it can "forget" stashes after a period of time
So far you've only attacked the first point, and your defense of the
second point has consisted of nothing more than an affirmation that
the status quo should remain in place because that's the way it's
always been. I haven't yet heard any explanation of _why_ it's such a
big deal to adjust the behaviour of the tool to match user
expectations, expectations created partly by poor documentation but
mostly by an unfortunate choice of name for the "stash" command.
We have a choice: re-educate users or modify the tool, and re-
education seems of questionable value (for what?) and much more
difficult than the latter, which has next to no cost at all. Modify
the tool and we won't have to re-educate users: those who abuse "git
stash" for long term storage will soon figure out that they're not
using it in the best possible way when their stash list gets out of
hand, and as an added bonus nobody will ever get burnt by Git throwing
away something that they thought it should have kept.
An auto-expiration config variable should be enough to keep people
like you happy, as you'll get to keep your auto-garbage-collected
stash list, but the auto-expiration should be _off_ by default because
it's best to err on the conservative side about throwing out data.
Especially in a case like this one where it is clearly demonstrated
that most people are surprised to learn that Git garbage collects old
stashes.
Anyway, I've now stated and restated these arguments enough times and
I don't think I have anything to add.
Wincent
--
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
