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

Jeff King <peff@peff.net> writes:

I personally do not find the example that Andreas gave unconvincing, not because I doubt it happens in practice, but because I think it shows a bad inter-developer communication.

It is natural to have branches that are private and/or not meant to be built on top of by others. We all have them --- heck, I have one that is called 'pu' (not private but it is meant to be "only look, never touch" and advertised as such). But if we need a strong mechanism to enforce that "never touch" policy by not allowing fetch, there is something wrong with the inter-developer communication.

While digging the original thread earlier today (eh, it is already yesterday here), I was thinking about what other alternative design and implementation would have been sensible. Here are some thoughts.

 * We _did not have to_ make stashes into refs/stash@{$N}.  We could have
   implemented them as individual refs under "refs/stash/$N" hierarchy.
   E.g. refs/stashes/1, refs/stash/2, etc.

   As a side note, we also could have implemented per-branch stash as
   refs/stashes/master@{$N} or refs/stashes/$branch/$N (and we still can.
   Perhaps we can have "git stash save -B" option that tells the command
   to send the resulting stash to the per-branch namespace).

 * We however chose to take advantage of the auto reclamation behaviour of
   reflog, and for most practical purposes, it is a good thing.

 * We later introduced "drop" because even as a volatile and short-lived
   collection of local modifications, you can tell that some stashes are
   utter crap immediately while deciding that some are worth keeping, even
   for a short term.

   This mechanism was however meant for uncluttering the set of stashes.
   "drop" names what you want to discard right now, and by doing so,
   implicitly names what you want to keep for a bit longer (by not naming
   them).  It's a reverse operation -- to make your gems easier to find,
   you discard garbage stash entries.  It is a useful work element.

 * We could add "keep" which is a complementary operation to "drop".  This
   would mark a stash as a gem in a more direct way, excempt even from the
   usual auto pruning.

   We probably implement this by marking the entry with a magic timestamp
   value, and teach reflog expiry machinery to keep it indefinitely.  You
   can still explicitly "drop" it.

I do not want to conflate two possibly independent issues, but I wonder if there is a correlation between a change that people would want to stash to a per-branch stash (if such a thing existed) and a change the people would want to "keep" (if such a feature existed).

If there is a strong correlation between the two, one possible solution would be to introduce refs/stashes/$branch/ namespace that holds each stash as an individual, numbered ref under it. They will live forever until the user explicitly asks for their removal. If we go this route, we would need a few niceties such as a way to move a "quick stash" that is represented as a reflog entry into a "longlived stash" that is represented as an individual ref under refs/stashes/$branch/.

But let's not talk nor think about per-branch stash for now. How does the "keep" thing sound to people?