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
Andreas Ericsson <ae@op5.se>
Date
Jun 13, 2008, 04:26 UTC
Message-ID
<4851F6F4.8000503@op5.se>
In-Reply-To
<6413041E-A64A-4BF4-9ECF-F7BFA5C1EAEF@wincent.com>
Wincent Colaiuta wrote:
Show 35 quoted lines
> 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.
Show 5 quoted lines
> 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
Previous: しらいしななこNext: Jeff King
Message 34 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.