git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Andreas Ericsson <ae@op5.se>
Cc: Wincent Colaiuta <win@wincent.com>,
	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 03:42:57 -0400	[thread overview]
Message-ID: <20080613074257.GA513@sigill.intra.peff.net> (raw)
In-Reply-To: <48521EDA.5040802@op5.se>

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?" :)

I'm not, by the way, trying to say "there is no good reason not to use a
branch." I am trying to figure out what the reasons are, because I
wonder if there is a more useful abstraction we can come up for handling
this situation.

Reading your (and others') responses, it seems like there are two
things:

  1. Stashing is about saying "save everything about where I am now with
     no hassle". IOW, it's one command, you don't have to decide what
     goes and what stays, and you can pull it back out with one command.
     And maybe there is a psychological component that you are not ready
     to "commit" such a work-in-progress (I am extrapolating here, but I
     know that when I first started with git, I was hesitant to commit
     because of my experience with other systems).

  2. Branches tend to get shared, and you don't want people to see your
     stashes, because they are messy works in progress.

To deal with '2', I wonder if it would be worth making some branches
inaccessible to pushing/pulling (either via config, or through a special
naming convention).

For '1', I guess the only solution would be some way of making a topic
branch easy to stash and restore. And that would end up looking quite a
bit like stash; I would think the interface would be "git notstash
branchname". Which we sort of have with "git stash save <message>"
already. We could say "if you didn't provide a message, then it will be
gc'ed eventually, but if you did, then it lives forever". That would
work fine for my workflow (I don't bother naming stashes, since I
generally unstash them immediately). But it seems like an accident
waiting to happen for unsuspecting users.

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

-Peff

  reply	other threads:[~2008-06-13  7:44 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
2008-06-13  5:58                 ` Jeff King
2008-06-13  7:16                   ` Andreas Ericsson
2008-06-13  7:42                     ` Jeff King [this message]
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=20080613074257.GA513@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).