From: Andreas Ericsson <ae@op5.se>
To: Wincent Colaiuta <win@wincent.com>
Cc: Eric Raible <raible@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Nicolas Pitre <nico@cam.org>
Subject: Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs
Date: Fri, 13 Jun 2008 06:26:28 +0200 [thread overview]
Message-ID: <4851F6F4.8000503@op5.se> (raw)
In-Reply-To: <6413041E-A64A-4BF4-9ECF-F7BFA5C1EAEF@wincent.com>
Wincent Colaiuta wrote:
> El 12/6/2008, a las 6:32, Eric Raible escribió:
>
>> Nicolas Pitre <nico <at> cam.org> writes:
>>
>>> As you say, branches are there just for that: keeping changes for
>>> months. Stashes are not meant to be used like that nor should we
>>> encourage it.
>>
>> This unfortunately goes against the recommended usage in John Wiegley's
>> otherwise excellent "Git From the Bottom Up". I've contacted him
>> separately to
>> make him aware of the collective wisdom of not relying on stashes for
>> long-term
>> storage.
>
> Yes, we shouldn't _encourage_ people to use stashes as a long-term
> storage mechanism, but neither should we allow old stashes to silently
> disappear as a result of reflog expiry, especially as part of automatic
> garbage collection. There are two reasons:
>
> (1) Normal reflogs accumulate cruft automatically through normal use and
> if not cleaned up they'll just grow and grow and grow. On the other
> hand, for "git stash" to accumulate cruft over the long term the user
> actually has to take action and _abuse_ them. Abuse is less likely
> because it requires this conscious action, and as the output of "git
> stash list" gets bigger and more unwieldy this will serve to encourage
> people to clean out their stashes themselves, or not let the list grow
> out of control in the first place. In other words, the size of the stash
> reflog is unlikely to be a problem.
>
> (2) Automatically expiring normal reflogs is a service to the user,
> because it's cleaning up something that is automatically generated.
> Stashes are the result of a concious user decision to create them, so
> automatically "cleaning them up" is _not_ going to help the user.
>
I agree.
> So yes, branches _are_ better and more appropriate for long term storage
> than stashes, but even so I don't think it's right for us to risk
> throwing away information that the user explicitly stashed and expected
> Git to look after for them.
>
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2008-06-13 4:27 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <OLvkESB0JjBNs9kF8Q2M5UFNBJqq4FjbgGeQVyWstGwcXqCOq16_oomM0y-utOBbV7BnndyrICE@cipher.nrlssc.navy.mil>
2008-06-11 21:29 ` [PATCH 2/2] git-gc: skip stashes when expiring reflogs Brandon Casey
2008-06-11 21:36 ` Mike Hommey
2008-06-11 21:44 ` Johannes Schindelin
2008-06-11 23:03 ` Jeff King
2008-06-11 23:21 ` Nicolas Pitre
2008-06-12 4:32 ` Eric Raible
2008-06-12 5:35 ` Wincent Colaiuta
2008-06-12 14:14 ` Nicolas Pitre
2008-06-12 20:13 ` Junio C Hamano
2008-06-12 20:35 ` Eric Raible
2008-06-12 20:51 ` Junio C Hamano
2008-06-12 21:36 ` Eric Raible
2008-06-13 4:52 ` Johannes Schindelin
2008-06-13 8:43 ` Wincent Colaiuta
2008-06-13 9:13 ` Jeff King
2008-06-13 21:41 ` Johannes Schindelin
2008-06-13 23:33 ` Christian Jaeger
2008-06-14 8:58 ` Wincent Colaiuta
2008-06-14 23:59 ` しらいしななこ
[not found] ` <200806142359.m5ENxsBL028758@mi0.bluebottle.com>
2008-06-15 4:00 ` Johannes Schindelin
[not found] ` <200806142359.m5ENxsBI028758 @mi0.bluebottle.com>
2008-06-15 5:07 ` Junio C Hamano
2008-06-16 3:33 ` Eric Raible
2008-06-16 7:21 ` Junio C Hamano
2008-06-17 9:05 ` Johannes Schindelin
2008-06-17 21:54 ` Junio C Hamano
2008-06-18 15:25 ` Johannes Schindelin
2008-06-18 18:58 ` Junio C Hamano
2008-06-16 16:30 ` Brandon Casey
2008-06-16 16:52 ` Jakub Narebski
2008-06-13 12:05 ` Mikael Magnusson
2008-06-12 21:27 ` Brandon Casey
2008-06-12 21:46 ` Junio C Hamano
2008-06-12 22:10 ` Brandon Casey
2008-06-13 3:45 ` しらいしななこ
2008-06-13 4:26 ` Andreas Ericsson [this message]
2008-06-13 5:58 ` Jeff King
2008-06-13 7:16 ` Andreas Ericsson
2008-06-13 7:42 ` Jeff King
2008-06-13 8:11 ` Andreas Ericsson
2008-06-13 8:51 ` Jakub Narebski
2008-06-13 8:56 ` Sverre Rabbelier
2008-06-13 9:10 ` Jeff King
2008-06-13 11:14 ` Miles Bader
2008-06-13 9:47 ` Junio C Hamano
2008-06-13 10:05 ` Jakub Narebski
2008-06-13 10:33 ` Sverre Rabbelier
2008-06-13 17:31 ` Olivier Marin
2008-06-13 19:21 ` Junio C Hamano
2008-06-13 19:35 ` Wincent Colaiuta
2008-06-13 19:42 ` Brandon Casey
2008-06-13 19:49 ` Olivier Marin
2008-06-14 1:16 ` しらいしななこ
2008-06-13 12:40 ` Wincent Colaiuta
2008-06-13 13:11 ` Jeff King
2008-06-13 17:03 ` Olivier Marin
2008-06-13 13:54 ` Jon Loeliger
2008-06-13 16:54 ` Brandon Casey
2008-06-11 23:25 ` Brandon Casey
2008-06-12 4:18 ` Jeff King
2008-06-12 16:46 ` Brandon Casey
2008-06-13 5:48 ` Jeff King
2008-06-13 8:41 ` Wincent Colaiuta
2008-06-13 8:53 ` Sverre Rabbelier
2008-06-13 9:07 ` Teemu Likonen
2008-06-13 9:04 ` Jeff King
2008-06-13 11:22 ` Miles Bader
2008-06-13 16:43 ` Brandon Casey
2008-06-13 17:30 ` Jeff King
2008-06-11 22:35 ` Brandon Casey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4851F6F4.8000503@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=nico@cam.org \
--cc=raible@gmail.com \
--cc=win@wincent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.