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
Junio C Hamano <gitster@pobox.com>
Date
Jun 13, 2008, 19:21 UTC
Message-ID
<7v3anhuonj.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<bd6139dc0806130333n2cfbc564k79ed5562f14fc848@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
Show 16 quoted lines
> On Fri, Jun 13, 2008 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> <big snip>
>
>> But let's not talk nor think about per-branch stash for now.  How does the
>> "keep" thing sound to people?
>
> I'm divided on this:
>  OOH: I like the idea of having a keep command to mark stashes as
> valuable, making them not expire until dropped explicitly. Such a
> feature would also encourage user to go through their stashes every
> now and then and decide which ones are valuable, and which ones were
> indeed not that valuable and may be dropped.
>
>  OTOH: I dislike the idea of 'forcing' the users to go through their
> stashes lest they lose their work.
The latter argument is somewhat misguided.

To stash is like putting something in /tmp on a system that runs a cron job to clean out cruft from there once in a while. Another analogy is to spitting an information out to syslog, so that it is kept until logs are rotated.

If you want permanent storage, you do not store it in somewhere that is designed to have automated rotation or pruning. Instead, you would create a file somewhere in your $HOME or use a branch. It is natural that you do not have perfect foresight --- so after putting something in /tmp, you may wish that you can somehow say retroactively that some things you placed earlier in /tmp are more valuable than others. "keep" was an example of how you _could_ express that wish. In other words, you are not _forced_ to, but you are merely given an opportunity to do so.

I do not personally care too deeply about the "keep" approach. An easier to explain (and perhaps easier to implement, too) alternative would be to have a per-ref configuration variable that specifies the reflog retention period per ref, e.g. "git config reflog.refs/stash.expire never".

I however mildly suspect that the stash configured as such would end up to be a lot worse than the current behaviour in practice. It would make crufts easily accumulate in the stash, making it harder to find gems, and as a consequence of that, encouraging you to say "stash clean" or "stash drop" more often, risking accidental removal of what you did not intend to (for this exact reason I earlier -- much earlier than the current thread -- even thought about suggesting to make the reflog expiry period much shorter than the usual ref).

But at that point it is user shooting his foot off ;-)
Previous: Olivier MarinNext: Wincent Colaiuta
Message 47 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.