From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:44
Jeff King [off-list ref] 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?
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:44
Junio C Hamano [off-list ref] writes:
* We however chose to take advantage of the auto reclamation behaviour of
reflog, and for most practical purposes, it is a good thing.
By the way, this makes stashes a bit similar to using $TMPDIR to store
files with 'tmpwatch' (or equivalent) enabled. Is this a good analogy?
[...]
But let's not talk nor think about per-branch stash for now. How does the
"keep" thing sound to people?
This looks nice, although I'd rather not use any magic. I'm only
afraid that people would notice that some stash / stash entry should
have been "kept" when it is too late.
--
Jakub Narebski
Poland
ShadeHawk on #git
On Fri, Jun 13, 2008 at 11:47 AM, Junio C Hamano [off-list ref] 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. I don't see why anybody would want
to do some work, stash it, and then "for no apparent reason" (the
reason being not touching it for some time) lose it later. What if
their system borks up and gives a wrong value as current time (say, 10
years in the future), all of a sudden their stashes are gone, and they
might not even find out till it was too late. Sure, they'd lose some
stale objects too, but that I can live with, those they did not ask
git to take care of explicitly!
The per-branch stashes sounds very nice, especially if you can get a
'git stash list --all' feature, that shows all stashes, regardless of
what branch they are on. I myself would use such a per-branch feature
most of the time, it would be nice to have a config option that
defaults to that (making 'git stash' create a per-branch stash by
default that is).
--
Cheers,
Sverre Rabbelier
El 13/6/2008, a las 11:47, Junio C Hamano escribió:
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?
Sounds a little bit over-engineered to me.
So, "stash" is intended for short-term storage, but by adding a "keep"
option you're officially blessing it for long-term storage as well.
And the interface that you propose, explicitly marking stuff as "for
keeps" and being able to move stuff from "temp" to "keep" sounds quite
complicated.
I honestly think that the simplest solution from both an
implementation and a usage perspective is just to keep everything that
is stashed until the user clears it out. If you use a push/pop model
then your stash will never get cluttered up with garbage, and if you
do abuse it for long-term storage you'll start to notice that the
stash list is inconveniently large, thus hinting that perhaps you are
abusing stash in ways that the designers never intended.
Cheers,
Wincent
From: Jeff King <hidden> Date: 2016-06-15 22:44:44
On Fri, Jun 13, 2008 at 02:40:50PM +0200, Wincent Colaiuta wrote:
Sounds a little bit over-engineered to me.
So, "stash" is intended for short-term storage, but by adding a "keep"
option you're officially blessing it for long-term storage as well. And
the interface that you propose, explicitly marking stuff as "for keeps"
and being able to move stuff from "temp" to "keep" sounds quite
complicated.
I agree. I like the expiration of stashes, but if it is a choice between
"just don't expire them" and "here is a complex set of rules and
obligations for preventing them from expiring" I think we are better off
just leaving them.
-Peff
* 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.
I don't really see what is the need for "global" stashes but why not?
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).
I really like your refs/stashes/$branch/$N idea because it seems easier to
list and clean with git stash list/drop/clear.
But I think stash should stay a per-branch thing by default. What about a
-g (--global) option instead?
* 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.
"drop" is nice, but I think the real improvement was "pop".
* 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.
I don't like it at all. Why not just have "keep" by default? The users can
already use "pop", "drop" and "clear" if they want to trash their stash.
Olivier.
OTOH: I dislike the idea of 'forcing' the users to go through their
stashes lest they lose their work. I don't see why anybody would want
to do some work, stash it, and then "for no apparent reason" (the
reason being not touching it for some time) lose it later.
I agree. And even without that:
What if
their system borks up and gives a wrong value as current time (say, 10
years in the future), all of a sudden their stashes are gone, and they
might not even find out till it was too late. Sure, they'd lose some
stale objects too, but that I can live with, those they did not ask
git to take care of explicitly!
it seems pretty strange to ask the user for a confirmation: are you sure
you want to keep what you ask us to store in the stash?
The per-branch stashes sounds very nice, especially if you can get a
'git stash list --all' feature, that shows all stashes, regardless of
what branch they are on. I myself would use such a per-branch feature
most of the time, it would be nice to have a config option that
defaults to that (making 'git stash' create a per-branch stash by
default that is).
I think the same and would prefer per-branch stash by default because I
don't see a real use of a "global" one but maybe I'm wrong. Perhaps, a
config option could make everyone happy. :-)
Olivier.