git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs

From
Jeff King <peff@peff.net>
Date
Jun 13, 2008, 07:42 UTC
Message-ID
<20080613074257.GA513@sigill.intra.peff.net>
In-Reply-To
<48521EDA.5040802@op5.se>
On Fri, Jun 13, 2008 at 09:16:42AM +0200, Andreas Ericsson wrote:
Show 5 quoted lines
> 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.

Show 7 quoted lines
> 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
Previous: Andreas EricssonNext: Andreas Ericsson
Message 37 of 69 in “git-gc: skip stashes when expiring reflogs”
  1. 2/2 git-gc: skip stashes when expiring reflogsBrandon Casey, Jun 11, 2008
  2. Mike HommeyJun 11, 2008
  3. Johannes SchindelinJun 11, 2008
  4. Jeff KingJun 11, 2008
  5. Nicolas PitreJun 11, 2008
  6. Eric RaibleJun 12, 2008
  7. Wincent ColaiutaJun 12, 2008
  8. Nicolas PitreJun 12, 2008
  9. Junio C HamanoJun 12, 2008
  10. Eric RaibleJun 12, 2008
  11. Junio C HamanoJun 12, 2008
  12. Eric RaibleJun 12, 2008
  13. Johannes SchindelinJun 13, 2008
  14. Wincent ColaiutaJun 13, 2008
  15. Jeff KingJun 13, 2008
  16. Johannes SchindelinJun 13, 2008
  17. Christian JaegerJun 13, 2008
  18. Wincent ColaiutaJun 14, 2008
  19. しらいしななこJun 14, 2008
  20. Junio C HamanoJun 15, 2008
  21. Eric RaibleJun 16, 2008
  22. Junio C HamanoJun 16, 2008
  23. Johannes SchindelinJun 17, 2008
  24. Junio C HamanoJun 17, 2008
  25. Johannes SchindelinJun 18, 2008
  26. Junio C HamanoJun 18, 2008
  27. Brandon CaseyJun 16, 2008
  28. Jakub NarebskiJun 16, 2008
  29. Mikael MagnussonJun 13, 2008
  30. Brandon CaseyJun 12, 2008
  31. Junio C HamanoJun 12, 2008
  32. Brandon CaseyJun 12, 2008
  33. しらいしななこJun 13, 2008
  34. Andreas EricssonJun 13, 2008
  35. Jeff KingJun 13, 2008
  36. Andreas EricssonJun 13, 2008
  37. Jeff KingJun 13, 2008
  38. Andreas EricssonJun 13, 2008
  39. Jakub NarebskiJun 13, 2008
  40. Sverre RabbelierJun 13, 2008
  41. Jeff KingJun 13, 2008
  42. Miles BaderJun 13, 2008
  43. Junio C HamanoJun 13, 2008
  44. Jakub NarebskiJun 13, 2008
  45. Sverre RabbelierJun 13, 2008
  46. Olivier MarinJun 13, 2008
  47. Junio C HamanoJun 13, 2008
  48. Wincent ColaiutaJun 13, 2008
  49. Brandon CaseyJun 13, 2008
  50. Olivier MarinJun 13, 2008
  51. しらいしななこJun 14, 2008
  52. Wincent ColaiutaJun 13, 2008
  53. Jeff KingJun 13, 2008
  54. Olivier MarinJun 13, 2008
  55. Jon LoeligerJun 13, 2008
  56. Brandon CaseyJun 13, 2008
  57. Brandon CaseyJun 11, 2008
  58. Jeff KingJun 12, 2008
  59. Brandon CaseyJun 12, 2008
  60. Jeff KingJun 13, 2008
  61. Wincent ColaiutaJun 13, 2008
  62. Sverre RabbelierJun 13, 2008
  63. Teemu LikonenJun 13, 2008
  64. Jeff KingJun 13, 2008
  65. Miles BaderJun 13, 2008
  66. Brandon CaseyJun 13, 2008
  67. Jeff KingJun 13, 2008
  68. Brandon CaseyJun 11, 2008
  69. Johannes SchindelinJun 15, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.