Jeff King <peff@xxxxxxxx> writes:
> 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).
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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
