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

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

[Brandon Casey]

The stash makes use of git's reflog mechanism, but it is not a reflog
in the traditional sense. Each entry is a state that the user explicitly
requested git to remember. The stash is generally short-lived, but the
user probably expects that a stash will continue to exist until it is
explicitly deleted. So we should not expire stash entries.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
 builtin-gc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-gc.c b/builtin-gc.c
index f5625bb..5cb74ec 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -30,7 +30,7 @@ static char *prune_expire = "2.weeks.ago";
 
 #define MAX_ADD 10
 static const char *argv_pack_refs[] = {"pack-refs", "--all", "--prune", NULL};
-static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
+static const char *argv_reflog[] = {"reflog", "expire", "--all", "--exclude=refs/stash", NULL};
 static const char *argv_repack[MAX_ADD] = {"repack", "-d", "-l", NULL};
 static const char *argv_prune[] = {"prune", "--expire", NULL, NULL};
 static const char *argv_rerere[] = {"rerere", "gc", NULL};
-- 
1.5.5.3

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

[Mike Hommey]

On Wed, Jun 11, 2008 at 04:29:56PM -0500, Brandon Casey wrote:
> The stash makes use of git's reflog mechanism, but it is not a reflog
> in the traditional sense. Each entry is a state that the user explicitly
> requested git to remember. The stash is generally short-lived, but the
> user probably expects that a stash will continue to exist until it is
> explicitly deleted. So we should not expire stash entries.

I wonder if it wouldn't make sense to have git reflog expire not expire
stashes *at all*. I mean, you don't necessarily cleanup your repo with
git gc, and you may end up killing your stashes with git reflog yourself
if you don't use the "magic" --exclude...

Mike

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

[Johannes Schindelin]

Hi,

On Wed, 11 Jun 2008, Mike Hommey wrote:

> On Wed, Jun 11, 2008 at 04:29:56PM -0500, Brandon Casey wrote:
> > The stash makes use of git's reflog mechanism, but it is not a reflog 
> > in the traditional sense. Each entry is a state that the user 
> > explicitly requested git to remember. The stash is generally 
> > short-lived, but the user probably expects that a stash will continue 
> > to exist until it is explicitly deleted. So we should not expire stash 
> > entries.
> 
> I wonder if it wouldn't make sense to have git reflog expire not expire 
> stashes *at all*. I mean, you don't necessarily cleanup your repo with 
> git gc, and you may end up killing your stashes with git reflog yourself 
> if you don't use the "magic" --exclude...

FWIW I thought it was one of the clever designs of git-stash that it 
automatically expires together with the other reflogs.  A stash is only a 
temporary thing, that is not even meant to leave the local repository, 
after all.

Ciao,
Dscho

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

[Jeff King]

On Wed, Jun 11, 2008 at 10:44:17PM +0100, Johannes Schindelin wrote:

> FWIW I thought it was one of the clever designs of git-stash that it 
> automatically expires together with the other reflogs.  A stash is only a 
> temporary thing, that is not even meant to leave the local repository, 
> after all.

I agree. If you are concerned about valuable stashes getting deleted, my
guess is one of:

  - you would like reflog expiration to be longer

  - you are using stash as a long-term storage, which it was never
    intended for. Use a branch.

The latter, of course, is based on my use and my impression of others
use (I almost always apply a stash within 30 seconds of having stashed
it). So maybe everyone is keeping stashes around for months, and this is
a useful change.

-Peff

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

[Nicolas Pitre]

On Wed, 11 Jun 2008, Jeff King wrote:

> I agree. If you are concerned about valuable stashes getting deleted, my
> guess is one of:
> 
>   - you would like reflog expiration to be longer
> 
>   - you are using stash as a long-term storage, which it was never
>     intended for. Use a branch.
> 
> The latter, of course, is based on my use and my impression of others
> use (I almost always apply a stash within 30 seconds of having stashed
> it). So maybe everyone is keeping stashes around for months, and this is
> a useful change.

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.


Nicolas

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

[Eric Raible]

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.

- Eric

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

[Wincent Colaiuta]

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.

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.

Wincent

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

[Nicolas Pitre]

On Thu, 12 Jun 2008, Wincent Colaiuta wrote:

> 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.
> 
> 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.

Fair enough.


Nicolas

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

[Junio C Hamano]

Wincent Colaiuta <win@wincent.com> writes:

> 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.

Yes, but for a limited amount of time.

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

[Eric Raible]

On Thu, Jun 12, 2008 at 1:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> 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.
>
> Yes, but for a limited amount of time.
>

A limited amount of time?  Why is that?  Can you give a rationale which
at least addresses Wincent's points?

It's bad enough that 'git stash clear' drops all pending stashes w/out
at least echoing them (the way git stash drop does), but what is the
rationale for having git _ever_ forget information which it was specifically
requested to remember?

I know that stash is implemented in terms of reflogs, but that seems
to me an implementation detail which ought not leak out.  Especially
if that leakage ends up forgetting potentially important data.

- Eric

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

[Junio C Hamano]

"Eric Raible" <raible@gmail.com> writes:

> On Thu, Jun 12, 2008 at 1:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Wincent Colaiuta <win@wincent.com> writes:
>>
>>> 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.
>>
>> Yes, but for a limited amount of time.
>
> A limited amount of time?  Why is that?  Can you give a rationale which
> at least addresses Wincent's points?

Perhaps

 http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670

The user explicitly asks to stash it for a while, where the definition of
the "while" comes from reflog's retention period.

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

[Eric Raible]

On Thu, Jun 12, 2008 at 1:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Perhaps
>
>  http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670
>
> The user explicitly asks to stash it for a while, where the definition of
> the "while" comes from reflog's retention period.

But that doesn't answer the basic question as to why it's ok
to trash data that the user explicitly asked git to save?

The fact that stash is implemented in terms of reflogs seems irrelevant to me.
If stash were implemented via branches and cherry picking would it still be
natural to automatically expire them?

At the very least the man page might want to mention the temporary nature
of stashes.  Better yet when 'git stash' could print that out when creating
the stash, eh?

- Eric

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

[Johannes Schindelin]

Hi,

On Thu, 12 Jun 2008, Eric Raible wrote:

> On Thu, Jun 12, 2008 at 1:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Perhaps
> >
> >  http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670
> >
> > The user explicitly asks to stash it for a while, where the definition of
> > the "while" comes from reflog's retention period.
> 
> But that doesn't answer the basic question as to why it's ok
> to trash data that the user explicitly asked git to save?

If the user really asked git to save the changes, she would have 
_committed_ them.

"git stash" really is only about shelving quickly and dirtily something 
you'll need (or maybe need) in a moment.

If you need something from the stash a day after stashing it, you have a 
serious problem with understanding what branches are for.

Ciao,
Dscho

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

[Wincent Colaiuta]

El 13/6/2008, a las 6:52, Johannes Schindelin escribió:

> Hi,
>
> On Thu, 12 Jun 2008, Eric Raible wrote:
>
>> On Thu, Jun 12, 2008 at 1:51 PM, Junio C Hamano <gitster@pobox.com>  
>> wrote:
>>> Perhaps
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670
>>>
>>> The user explicitly asks to stash it for a while, where the  
>>> definition of
>>> the "while" comes from reflog's retention period.
>>
>> But that doesn't answer the basic question as to why it's ok
>> to trash data that the user explicitly asked git to save?
>
> If the user really asked git to save the changes, she would have
> _committed_ them.
>
> "git stash" really is only about shelving quickly and dirtily  
> something
> you'll need (or maybe need) in a moment.
>
> If you need something from the stash a day after stashing it, you  
> have a
> serious problem with understanding what branches are for.

While this may be true for codebases which move forward quickly, what  
about one which is basically finished and tends not to get touched in  
a long time. A situation arises, you stash something, the phone rings,  
and for whatever reason the stash gets forgotten and you don't revisit  
the project at all for days, weeks, months. It wouldn't be nice to  
eventually come back and discover that your in-progress work had been  
"garbage" collected for you.

Wincent

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

[Jeff King]

On Fri, Jun 13, 2008 at 10:43:59AM +0200, Wincent Colaiuta wrote:

> While this may be true for codebases which move forward quickly, what  
> about one which is basically finished and tends not to get touched in a 
> long time. A situation arises, you stash something, the phone rings, and 
> for whatever reason the stash gets forgotten and you don't revisit the 
> project at all for days, weeks, months. It wouldn't be nice to eventually 
> come back and discover that your in-progress work had been "garbage" 
> collected for you.

I think this argues more for increasing the expiration period on
reflogs, if your project moves very slowly.

-Peff

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1002 bytes --]

Hi,

On Fri, 13 Jun 2008, Wincent Colaiuta wrote:

> El 13/6/2008, a las 6:52, Johannes Schindelin escribió:
> 
> >If you need something from the stash a day after stashing it, you have 
> >a serious problem with understanding what branches are for.
> 
> While this may be true for codebases which move forward quickly, what 
> about one which is basically finished and tends not to get touched in a 
> long time. A situation arises, you stash something, the phone rings, and 
> for whatever reason the stash gets forgotten and you don't revisit the 
> project at all for days, weeks, months. It wouldn't be nice to 
> eventually come back and discover that your in-progress work had been 
> "garbage" collected for you.

You cannot be serious about not wanting to lose the changes when you keep 
them in _one_ _single_ repository anyway.

And you cannot be serious about not wanting to lose the changes when you 
forget about them, for months, even.

So you are making my point for me.

Thanks,
Dscho

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

[Christian Jaeger]

Johannes Schindelin wrote:
> You cannot be serious about not wanting to lose the changes when you keep 
> them in _one_ _single_ repository anyway.
>
> And you cannot be serious about not wanting to lose the changes when you 
> forget about them, for months, even.
>
> So you are making my point for me.
>   

Maybe I should describe my way of using Git?:

- I'm (amongst other things) using Git for keeping my own codebase for 
server maintenance scripts etc, which I then casually replicate between 
my servers through Git's networking and merging mechanisms. When I need 
a new feature, I'm coding it on the particular server where I need it 
and commit it there (I'm even using separate email adresses on every 
server so that I can track back on which server I wrote a particular 
feature).

- every now and then, I'm being interrupted when I'm coding something 
(and will not be able to continue on it for days, weeks or months); when 
I return to the repo for something completely different, there's an 
uncommitted file or two or more (all of which might not even work), and 
before there was git-stash I would sometimes just let those stay around 
uncommitted in the working tree; this was a bit of a hassle since I 
could for example not use "git commit -a", would IIRC have problems 
merging changes coming from another repo into those files, and once more 
than one case of unfinished work accumulated, I could no longer tell 
what belonged together; I didn't want it to commit to branches because 
that didn't seem like a good fit to me (more on that below). Then when 
git-stash came around, I first thought, "what's *that*, Git has branches 
already?", but then I realized that it would be a perfect fit for 
handling those unfinished uncommitted things.
   So note that my use case is putting away work which was not finished 
(and usually by accident, i.e. I didn't have the time to choose a 
sensible interruption point and think of a commit message--I'll actually 
usually run "git stash save" not upon interruption, but later when I 
want to do other operations in the same repo), to hopefully be picked up 
again some (maybe long) time later. (I guess the use case it was 
designed for was putting temporarily away intermediate stages of 
conflicting merges and such stuff, i.e. for working as maintainer and 
not coder?)

- I do backups of the servers. So I don't expect loosing my work even if 
it's only being stored on one server.

- But I was not aware of the expiry policy (missing clarity in the man 
page). So I think I may actually *have* lost some such work already. 
Probably not a big deal, but a bit of a nuisance nonetheless (I wouldn't 
continue using git-stash(*)).

You said in a previous mail "If you need something from the stash a day 
after stashing it, you have a
serious problem with understanding what branches are for." I've now 
spent a bit of thinking about how to use branches easily for that; 
should git stash keep the expiry behaviour, I'll need an easy way of 
dealing with those uncommitted things; basically git stash onto a 
branch. Since I want it to use a default commit message, and when 
applying it I want the WIP commit undone, I basically want all of the 
same functionality but using a branch as storage instead. Now, what 
would be the name of the branch? (Is this calling for discussion of 
hierarchical branch namespaces?). It would need to be such that it 
wouldn't accidentally interfere with WIP branches on other servers--it's 
two different works in progress, so using the same branch name would be 
wrong, unless the source prefix ("origin/" etc.) separates names well 
enough to not lead to accidents (I don't have enough experience in this 
area; when I'm on branch foo, would "git pull" merge another server's 
foo branch into the current wip branch? etc.).

((*)BTW regarding the comment from Jeff King about the comparison with 
vim's yank buffer and "bounding by time rather than by number of 
stashes": yes, why not bound the number of stashes instead? That would 
also work like history in bash or other tools which limit it by number 
of entries. But I guess the "preference for forgetting" is different for 
everyone. Anyway, in my above use case I'm not sure I want the machine 
make things forgotten for me; would it reduce my work by just not 
reminding me of undone work? Should I let HAL (a fictional intelligent 
computer) decide that I've got too much to do and he should decide I 
should forget about a few things every now and then? I don't have data 
at hand whether that would work and be beneficial for me; it tends to 
upset me when I cannot find info again I know has been somewhere--HAL 
can't really tell what *I* will forget, after all; I'll just feel like a 
looser when it happens. Would another analogy be: shouldn't Git drop 
history entries after, say, three years, since nobody should care about 
old stuff anymore by then?)

Maybe, if the list of stashes really grows unbounded for some people, 
there should be a tool to display stashes in the tree, instead of only 
listing them in linear form? i.e. gitk would show the stashes kind of 
like branches; of course there's also a linear list of branches--so 
maybe stashes *should* be branches but in a different namespace (a 
sub-local namespace), hence my thought above about hierarchical 
namespaces. To sum it all up: using branches makes sense to me, but the 
features that "git stash" offers (separated 'namespace' from normal 
branches, and the automatic "git reset HEAD^" for removing the WIP 
commit) are missing there yet.

Christian.

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

[Wincent Colaiuta]

El 13/6/2008, a las 23:41, Johannes Schindelin escribió:

> Hi,
>
> On Fri, 13 Jun 2008, Wincent Colaiuta wrote:
>
>> El 13/6/2008, a las 6:52, Johannes Schindelin escribió:
>>
>>> If you need something from the stash a day after stashing it, you  
>>> have
>>> a serious problem with understanding what branches are for.
>>
>> While this may be true for codebases which move forward quickly, what
>> about one which is basically finished and tends not to get touched  
>> in a
>> long time. A situation arises, you stash something, the phone  
>> rings, and
>> for whatever reason the stash gets forgotten and you don't revisit  
>> the
>> project at all for days, weeks, months. It wouldn't be nice to
>> eventually come back and discover that your in-progress work had been
>> "garbage" collected for you.
>
> You cannot be serious about not wanting to lose the changes when you  
> keep
> them in _one_ _single_ repository anyway.
>
> And you cannot be serious about not wanting to lose the changes when  
> you
> forget about them, for months, even.
>
> So you are making my point for me.

Your arguments are _totally_ spurious.

With respect to your first point, I didn't even mention repository  
duplication and backups so I don't know why you tried to inject it  
into the discussion. I am _completely_ serious about preserving my  
data in the repos I work on, and that's why I do automated backups of  
the home directory which contains all of my local working repos every  
two hours (ie 12 times per day), plus an automated whole-disk backup  
once every 24 hours. However, my point about "git stash" is completely  
independent of my backup regimen; the backup regimen exists to protect  
me against disk and system failures, not to protect me from my SCM.

And on your second point, you are arguing that anything you can't  
remember isn't worth keeping, which just isn't a sustainable argument.  
Can you remember the thousands of commits in Git's complete history?  
Would it be okay to just throw away the changes you've forgotten about?

So I don't think I've made your point for you at all; it remains for  
you to make it for yourself. But it seems to me that you are arguing  
against the sizeable majority of participants on this thread which has  
already dragged on too long.

So, let's recap:

(1) It is reasonable to expect, and in fact it is clear that most  
users _do_ expect, that Git should indefinitely remember changes that  
they told it to remember with "git stash save"

(2) The people largely responsible for the implementation of "git  
stash" never envisaged its use for long term storage (either  
intentional abuse of "stash", or inadvertent misuse) and architected  
it in such a way that it can "forget" stashes after a period of time

So far you've only attacked the first point, and your defense of the  
second point has consisted of nothing more than an affirmation that  
the status quo should remain in place because that's the way it's  
always been. I haven't yet heard any explanation of _why_ it's such a  
big deal to adjust the behaviour of the tool to match user  
expectations, expectations created partly by poor documentation but  
mostly by an unfortunate choice of name for the "stash" command.

We have a choice: re-educate users or modify the tool, and re- 
education seems of questionable value (for what?) and much more  
difficult than the latter, which has next to no cost at all. Modify  
the tool and we won't have to re-educate users: those who abuse "git  
stash" for long term storage will soon figure out that they're not  
using it in the best possible way when their stash list gets out of  
hand, and as an added bonus nobody will ever get burnt by Git throwing  
away something that they thought it should have kept.

An auto-expiration config variable should be enough to keep people  
like you happy, as you'll get to keep your auto-garbage-collected  
stash list, but the auto-expiration should be _off_ by default because  
it's best to err on the conservative side about throwing out data.  
Especially in a case like this one where it is clearly demonstrated  
that most people are surprised to learn that Git garbage collects old  
stashes.

Anyway, I've now stated and restated these arguments enough times and  
I don't think I have anything to add.

Wincent

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

[しらいしななこ]

Wincent Colaiuta <win@wincent.com> writes:

> (2) The people largely responsible for the implementation of "git
> stash" never envisaged its use for long term storage (either
> intentional abuse of "stash", or inadvertent misuse) and architected
> it in such a way that it can "forget" stashes after a period of time

I apologize for my lack of perfect foresight as the original
author of the command.  As I already said, I think expiration
period of reflogs that is configurable for each ref as suggested
earlier by Junio makes sense.

But changing the default expiration "never" for stash has its
own problem and I think we need to modify the way a stash entry
is created to solve it.

You will find in the DISCUSSION section of git-stash manual page
that a stash entry is represented as a commit that is a merge
between the commit the stash was made on (H), and a fake commit
whose tree records the contents of the index (I).  The merge
commit itself records the state of the files in the working
directory as its tree (W):

           .----W
          /    /
    -----H----I

If you do not expire stash forever, you will keep the history
behind the commit H.  This is unnecessary and is problematic
particularly if you rebase your branches frequently.

In order to apply a stash, all you need is the tree of the three
commits contained in this structure.  You do not need the
history behind commit H.

The following is a trial patch to change how a stash is recorded.
With this patch I do not think we will keep unnecessary commits
behind H in the repository even when a stash is kept forever.

diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..f4c4236 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -54,6 +54,9 @@ create_stash () {
 	fi
 	msg=$(printf '%s: %s' "$branch" "$head")
 
+	# create the base commit that is parentless
+	b_commit=$(printf 'base of %s\n' "$msg" | git commit-tree "HEAD:")
+
 	# state of the index
 	i_tree=$(git write-tree) &&
 	i_commit=$(printf 'index on %s\n' "$msg" |


-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Get a free email address with REAL anti-spam protection.
http://www.bluebottle.com/tag/1

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1088 bytes --]

Hi,

On Sun, 15 Jun 2008, しらいしななこ wrote:

> The following is a trial patch to change how a stash is recorded.
> With this patch I do not think we will keep unnecessary commits
> behind H in the repository even when a stash is kept forever.
> 
> diff --git a/git-stash.sh b/git-stash.sh
> index 4938ade..f4c4236 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -54,6 +54,9 @@ create_stash () {
>  	fi
>  	msg=$(printf '%s: %s' "$branch" "$head")
>  
> +	# create the base commit that is parentless
> +	b_commit=$(printf 'base of %s\n' "$msg" | git commit-tree "HEAD:")
> +

I think that this does not help the case of Wincent (which I do not agree 
with), as it does not prevent the stashes from expiring.

What your patch does, however, might be something people need to prevent 
unnecessary bloat of the object database, if they choose never to expire 
stashes.

However, it makes it harder to see where the stashed revision came from.

Besides, I think that your printf would look nicer as

	b_commit=$(echo "base of $msg" | git commit-tree HEAD^{tree})

Ciao,
Dscho

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

[Junio C Hamano]

しらいしななこ  <nanako3@bluebottle.com> writes:

> I apologize for my lack of perfect foresight as the original
> author of the command.  As I already said, I think expiration
> period of reflogs that is configurable for each ref as suggested
> earlier by Junio makes sense.

You do not need to be overly apologetic.

It's not your fault that the way you originally scratched your own itch is
already 90% useful to others in different context of theirs but with 10%
"caveat emptor".  Others owe kudos to you for what they're given, and the
way for them to thank you would be to scratch their own itch by filling
the remaining 10% to make it work better in their context, not by bitching
and quibbling on what the dictionary definition of the word "stash" is.

> But changing the default expiration "never" for stash has its
> own problem and I think we need to modify the way a stash entry
> is created to solve it.
> ...
> If you do not expire stash forever, you will keep the history
> behind the commit H.  This is unnecessary and is problematic
> particularly if you rebase your branches frequently.
>
> In order to apply a stash, all you need is the tree of the three
> commits contained in this structure.  You do not need the
> history behind commit H.
>
> The following is a trial patch to change how a stash is recorded.
> With this patch I do not think we will keep unnecessary commits
> behind H in the repository even when a stash is kept forever.

Keeping stashes indefinitely is a relatively easy change (even though
there may need design discussions on the cleanest way to do so) but nobody
so far seemed to have thought about the ramifications of doing so.  I am
glad somebody is thinking one step ahead, and I think what you raised is a
valid concern.  Crufts from rebases will usually be purged from repository
thanks to reflog autoexpiration, but if somebody keeps a stash that was
made on a commit that has long been rebased away, it will keep the rebased
commits pinned to the repository, and we are talking about indefinite
retention here.  People should get worried.

I suspect this won't be a huge issue, but the only reason behind that
suspicion is because I expect people won't have insane number of rebases
nor keep insane number of stash entries, so the extra cruft that is kept
behind the stash entries won't be insanely large.  But people are known to
be insane enough to break my expectations, so I'd say we should make
things safer before we make the change to keep stashes forever by default.

I think the steps from here on would be:

 - Apply the patch in your message I am responding to, so that a stash
   that is kept forever will not pin the unnecessary history behind it in
   the repository.  As you said there is no reason to make the base commit
   (H) actually the same as the commit in the true history --- the only
   thing we care about it is its tree object;

 - Design and decide the way to tell git to make stash entries unexpirable
   (or maybe have very long expiration period).  I am leaning toward a
   configuration option that lets you specify expiration period per ref,
   rather than marking individual reflog entries as I suggested earlier;

 - Make the default for new repositories' stash reflog expiry period
   "never", by setting the above configuration upon "git init".

None of the above should obviously be in 1.5.6, but I think even the third
step to the change the default would be acceptable in the next 1.6.0
release.

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

[Eric Raible]

2008/6/14 Junio C Hamano <gitster@pobox.com>:
> I think the steps from here on would be:
>
>  - Apply the patch in your message I am responding to, so that a stash
>   that is kept forever will not pin the unnecessary history behind it in
>   the repository.  As you said there is no reason to make the base commit
>   (H) actually the same as the commit in the true history --- the only
>   thing we care about it is its tree object;
>
>  - Design and decide the way to tell git to make stash entries unexpirable
>   (or maybe have very long expiration period).  I am leaning toward a
>   configuration option that lets you specify expiration period per ref,
>   rather than marking individual reflog entries as I suggested earlier;
>
>  - Make the default for new repositories' stash reflog expiry period
>   "never", by setting the above configuration upon "git init".
>
> None of the above should obviously be in 1.5.6, but I think even the third
> step to the change the default would be acceptable in the next 1.6.0
> release.

In addition, how about a new stash option "expire", as in:
git stash expire --before=2.weeks.ago

The default for expire should probably be default expiration period;
if set to "never" then a usage message could be printed.

I for one would choose "never", so the above would be a simple
way of cleaning up if/when too much cruft accumulates.

- Eric

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I think the steps from here on would be:
>
>  - Apply the patch in your message I am responding to, so that a stash
>    that is kept forever will not pin the unnecessary history behind it in
>    the repository.  As you said there is no reason to make the base commit
>    (H) actually the same as the commit in the true history --- the only
>    thing we care about it is its tree object;
>
>  - Design and decide the way to tell git to make stash entries unexpirable
>    (or maybe have very long expiration period).  I am leaning toward a
>    configuration option that lets you specify expiration period per ref,
>    rather than marking individual reflog entries as I suggested earlier;
>
>  - Make the default for new repositories' stash reflog expiry period
>    "never", by setting the above configuration upon "git init".
>
> None of the above should obviously be in 1.5.6, but I think even the third
> step to the change the default would be acceptable in the next 1.6.0
> release.

So here is the second step from the above list.  I did not write any test
nor docs, but if people are so keen to see permanent stashes supported, I
am reasonably sure that they will contribute by filling the gap even if I
do not do anything further ;-)

Obviously this will _not_ come anywhere near 'master' nor 'next' until
1.5.6 ships.

-- >8 --

From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 15 Jun 2008 23:48:46 -0700
Subject: [PATCH] Per-ref reflog expiry configuration

In addition to gc.reflogexpireunreachable and gc.reflogexpire, this lets
you set gc.<pattern>.reflogexpireunreachable and gc.<pattern>.reflogexpire
variables.

When "git reflog expire" expires reflog entry for $ref, the expiry timers
are taken from the first <pattern> that matches $ref (and if there isn't
the global default value is used).

For example, you could:

	[gc "refs/stash"]
		reflogexpire = never
		reflogexpireunreachable = never

	[gc "refs/remotes/*"]
		reflogexpire = 7 days
		reflogexpireunreachable = 3 days

	[gc]
		reflogexpire = 90 days
		reflogexpireunreachable = 30 days

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-reflog.c |  145 +++++++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 126 insertions(+), 19 deletions(-)

diff --git a/builtin-reflog.c b/builtin-reflog.c
index b151e24..eec14c7 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -269,7 +269,9 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
 	int status = 0;
 
 	memset(&cb, 0, sizeof(cb));
-	/* we take the lock for the ref itself to prevent it from
+
+	/*
+	 * we take the lock for the ref itself to prevent it from
 	 * getting updated.
 	 */
 	lock = lock_any_ref_for_update(ref, sha1, 0);
@@ -331,21 +333,119 @@ static int collect_reflog(const char *ref, const unsigned char *sha1, int unused
 	return 0;
 }
 
-static int reflog_expire_config(const char *var, const char *value, void *cb)
+static struct reflog_expire_cfg {
+	struct reflog_expire_cfg *next;
+	unsigned long expire_total;
+	unsigned long expire_unreachable;
+	size_t len;
+	char pattern[FLEX_ARRAY];
+} *reflog_expire_cfg, **reflog_expire_cfg_tail;
+
+static struct reflog_expire_cfg *find_cfg_ent(const char *pattern, size_t len)
 {
-	if (!strcmp(var, "gc.reflogexpire")) {
-		if (!value)
-			config_error_nonbool(var);
-		default_reflog_expire = approxidate(value);
+	struct reflog_expire_cfg *ent;
+
+	if (!reflog_expire_cfg_tail)
+		reflog_expire_cfg_tail = &reflog_expire_cfg;
+
+	for (ent = reflog_expire_cfg; ent; ent = ent->next)
+		if (ent->len == len &&
+		    !memcmp(ent->pattern, pattern, len))
+			return ent;
+
+	ent = xcalloc(1, (sizeof(*ent) + len));
+	memcpy(ent->pattern, pattern, len);
+	ent->len = len;
+	*reflog_expire_cfg_tail = ent;
+	reflog_expire_cfg_tail = &(ent->next);
+	return ent;
+}
+
+static int parse_expire_cfg_value(const char *var, const char *value, unsigned long *expire)
+{
+	if (!value)
+		return config_error_nonbool(var);
+	if (!strcmp(value, "never") || !strcmp(value, "false")) {
+		*expire = 0;
 		return 0;
 	}
-	if (!strcmp(var, "gc.reflogexpireunreachable")) {
-		if (!value)
-			config_error_nonbool(var);
-		default_reflog_expire_unreachable = approxidate(value);
+	*expire = approxidate(value);
+	return 0;
+}
+
+/* expiry timer slot */
+#define EXPIRE_TOTAL   01
+#define EXPIRE_UNREACH 02
+
+static int reflog_expire_config(const char *var, const char *value, void *cb)
+{
+	const char *lastdot = strrchr(var, '.');
+	unsigned long expire;
+	int slot;
+	struct reflog_expire_cfg *ent;
+
+	if (!lastdot || prefixcmp(var, "gc."))
+		return git_default_config(var, value, cb);
+
+	if (!strcmp(lastdot, ".reflogexpire")) {
+		slot = EXPIRE_TOTAL;
+		if (parse_expire_cfg_value(var, value, &expire))
+			return -1;
+	} else if (!strcmp(lastdot, ".reflogexpireunreachable")) {
+		slot = EXPIRE_UNREACH;
+		if (parse_expire_cfg_value(var, value, &expire))
+			return -1;
+	} else
+		return git_default_config(var, value, cb);
+
+	if (lastdot == var + 2) {
+		switch (slot) {
+		case EXPIRE_TOTAL:
+			default_reflog_expire = expire;
+			break;
+		case EXPIRE_UNREACH:
+			default_reflog_expire_unreachable = expire;
+			break;
+		}
 		return 0;
 	}
-	return git_default_config(var, value, cb);
+
+	ent = find_cfg_ent(var + 3, lastdot - (var+3));
+	if (!ent)
+		return -1;
+	switch (slot) {
+	case EXPIRE_TOTAL:
+		ent->expire_total = expire;
+		break;
+	case EXPIRE_UNREACH:
+		ent->expire_unreachable = expire;
+		break;
+	}
+	return 0;
+}
+
+static void set_reflog_expiry_param(struct cmd_reflog_expire_cb *cb, int slot, const char *ref)
+{
+	struct reflog_expire_cfg *ent;
+
+	if (slot == (EXPIRE_TOTAL|EXPIRE_UNREACH))
+		return; /* both given explicitly -- nothing to tweak */
+
+	for (ent = reflog_expire_cfg; ent; ent = ent->next) {
+		if (!fnmatch(ent->pattern, ref, 0)) {
+			if (!(slot & EXPIRE_TOTAL))
+				cb->expire_total = ent->expire_total;
+			if (!(slot & EXPIRE_UNREACH))
+				cb->expire_unreachable = ent->expire_unreachable;
+			return;
+		}
+	}
+
+	/* Nothing matched -- set the default value */
+	if (!(slot & EXPIRE_TOTAL))
+		cb->expire_total = default_reflog_expire;
+	if (!(slot & EXPIRE_UNREACH))
+		cb->expire_unreachable = default_reflog_expire_unreachable;
 }
 
 static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
@@ -353,6 +453,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
 	struct cmd_reflog_expire_cb cb;
 	unsigned long now = time(NULL);
 	int i, status, do_all;
+	int explicit_expiry = 0;
 
 	git_config(reflog_expire_config, NULL);
 
@@ -367,20 +468,18 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
 	cb.expire_total = default_reflog_expire;
 	cb.expire_unreachable = default_reflog_expire_unreachable;
 
-	/*
-	 * We can trust the commits and objects reachable from refs
-	 * even in older repository.  We cannot trust what's reachable
-	 * from reflog if the repository was pruned with older git.
-	 */
-
 	for (i = 1; i < argc; i++) {
 		const char *arg = argv[i];
 		if (!strcmp(arg, "--dry-run") || !strcmp(arg, "-n"))
 			cb.dry_run = 1;
-		else if (!prefixcmp(arg, "--expire="))
+		else if (!prefixcmp(arg, "--expire=")) {
 			cb.expire_total = approxidate(arg + 9);
-		else if (!prefixcmp(arg, "--expire-unreachable="))
+			explicit_expiry |= EXPIRE_TOTAL;
+		}
+		else if (!prefixcmp(arg, "--expire-unreachable=")) {
 			cb.expire_unreachable = approxidate(arg + 21);
+			explicit_expiry |= EXPIRE_UNREACH;
+		}
 		else if (!strcmp(arg, "--stale-fix"))
 			cb.stalefix = 1;
 		else if (!strcmp(arg, "--rewrite"))
@@ -400,6 +499,12 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
 		else
 			break;
 	}
+
+	/*
+	 * We can trust the commits and objects reachable from refs
+	 * even in older repository.  We cannot trust what's reachable
+	 * from reflog if the repository was pruned with older git.
+	 */
 	if (cb.stalefix) {
 		init_revisions(&cb.revs, prefix);
 		if (cb.verbose)
@@ -417,6 +522,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
 		for_each_reflog(collect_reflog, &collected);
 		for (i = 0; i < collected.nr; i++) {
 			struct collected_reflog *e = collected.e[i];
+			set_reflog_expiry_param(&cb, explicit_expiry, e->reflog);
 			status |= expire_reflog(e->reflog, e->sha1, 0, &cb);
 			free(e);
 		}
@@ -430,6 +536,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
 			status |= error("%s points nowhere!", ref);
 			continue;
 		}
+		set_reflog_expiry_param(&cb, explicit_expiry, ref);
 		status |= expire_reflog(ref, sha1, 0, &cb);
 	}
 	return status;
-- 
1.5.6.rc3.7.g336d0

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

[Johannes Schindelin]

Hi,

On Mon, 16 Jun 2008, Junio C Hamano wrote:

> From: Junio C Hamano <gitster@pobox.com>
> Date: Sun, 15 Jun 2008 23:48:46 -0700
> Subject: [PATCH] Per-ref reflog expiry configuration
> 
> In addition to gc.reflogexpireunreachable and gc.reflogexpire, this lets
> you set gc.<pattern>.reflogexpireunreachable and gc.<pattern>.reflogexpire
> variables.
> 
> When "git reflog expire" expires reflog entry for $ref, the expiry timers
> are taken from the first <pattern> that matches $ref (and if there isn't
> the global default value is used).
> 
> For example, you could:
> 
> 	[gc "refs/stash"]
> 		reflogexpire = never
> 		reflogexpireunreachable = never
> 
> 	[gc "refs/remotes/*"]
> 		reflogexpire = 7 days
> 		reflogexpireunreachable = 3 days
> 
> 	[gc]
> 		reflogexpire = 90 days
> 		reflogexpireunreachable = 30 days

Isn't this overkill?  I mean, we could just change git-stash to output a 
warning:

	Note: your changes have been stored temporarily.  If you need to 
	keep them permanently, consider putting them into a branch:

		git branch stashed-longer stash

Don't get me wrong: I think per-ref reflog expiry is nifty, but it may be 
_too_ nifty, i.e. so complicated only power-users will use it.

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Mon, 16 Jun 2008, Junio C Hamano wrote:
> ...
> Isn't this overkill?  I mean, we could just change git-stash to output a 
> warning:
>
> 	Note: your changes have been stored temporarily.  If you need to 
> 	keep them permanently, consider putting them into a branch:
>
> 		git branch stashed-longer stash

You are asking the question to a Wrong Person, as I never asked to have a
nonexpirable stash, but I would hate such a change to waste four lines
of my terminal every time I create a new stash.

Also making a "branch" in the "git branch" sense (iow, a local branch you
can build on top of) is not something you would want anyway, isn't it?
What is the workflow to resume working from there?

	$ git checkout stashed-longer
        $ git reset --soft HEAD^
        $ work more
        $ git commit

and losing the tip with "reset --soft" would be crucial.  Otherwise if you
make commits on top of it by mistake, you will have a funny merge in the
history behind that commit.  IOW

	$ git checkout stashed-longer
        $ work more
        $ git commit --amend

would not work.

Of course,

	$ git stash apply stashed-longer

would work but that is by accident, as at that point what you are feeding
"git stash" command is not really a name of a ref that is a stash.

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

[Johannes Schindelin]

Hi,

On Tue, 17 Jun 2008, Junio C Hamano wrote:

> Of course,
> 
> 	$ git stash apply stashed-longer
> 
> would work but that is by accident, as at that point what you are feeding
> "git stash" command is not really a name of a ref that is a stash.

It would not be by accident.  It would work because we designed git-stash 
to use refs to store working-directory vs index changes, and this command 
line you wrote was _exactly_ what I intended.

Ciao,
Dscho

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 17 Jun 2008, Junio C Hamano wrote:
>
>> Of course,
>> 
>> 	$ git stash apply stashed-longer
>> 
>> would work but that is by accident, as at that point what you are feeding
>> "git stash" command is not really a name of a ref that is a stash.
>
> It would not be by accident.  It would work because we designed git-stash 
> to use refs to store working-directory vs index changes, and this command 
> line you wrote was _exactly_ what I intended.

Well, it is.  For normal stash oriented operations such as

    $ git stash list stashed-longer
    $ git stash apply stashed-longer@{22}

won't work on them.  Only the quoted form works and that _is_ by accident.

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

[Brandon Casey]

Junio C Hamano wrote:
> しらいしななこ  <nanako3@bluebottle.com> writes:
> 
>> I apologize for my lack of perfect foresight as the original
>> author of the command.  As I already said, I think expiration
>> period of reflogs that is configurable for each ref as suggested
>> earlier by Junio makes sense.
> 
> You do not need to be overly apologetic.

I whole-heartedly second this.

> ... the
> way for them to thank you would be to scratch their own itch by filling
> the remaining 10% to make it work better in their context, not by bitching
> and quibbling on what the dictionary definition of the word "stash" is.

I think you're being a little unfair here on two points:

 1) I think it is a valid point that the name of the command and it's
    subcommand "save" have contributed to the confusion by those who were
    not involved in the implementation of the stash feature.

 2) A patch _has_ been offered and there has been no discussion of the
    merits of that patch, only on why the stash should be persistent or not.

You have suggested two alternatives, one (--keep) was not commented on
favorably by anyone, and the other was not really commented on at all.

Besides, the point (for those arguing it) was not that users should
have the option to keep stashes, it was that keeping stashes
_by_default_ is the option of least surprise and doing so modifies the
stash behavior to match user expectations. So up until now, there has
been no reason for anyone to offer any alternative patch, since "--keep"
is not satisfactory and per reflog expiration _alone_ does not solve what
people think the problem is (that stashes expire by default).

Your suggestion of per reflog expiration, along with a default
configuration of never for the stash reflog expiration, _does_ solve
the problem. Time will tell if this feature is useful outside of
controlling the stash reflog expiration.

-brandon

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

[Jakub Narebski]

Brandon Casey wrote:

> Your suggestion of per reflog expiration, along with a default
> configuration of never for the stash reflog expiration, _does_ solve
> the problem. Time will tell if this feature is useful outside of
> controlling the stash reflog expiration.

I think that different expiration periods for regular branches (long),
remote-tracking branches (short), stash (never), and HEAD (perhaps
longes) are a very good idea.

For example reflog for "pu" branch might pin quite a large amount
of non-interesting objects, protecting these unnecessarily.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Mikael Magnusson]

2008/6/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Thu, 12 Jun 2008, Eric Raible wrote:
>
>> On Thu, Jun 12, 2008 at 1:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> > Perhaps
>> >
>> >  http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670
>> >
>> > The user explicitly asks to stash it for a while, where the definition of
>> > the "while" comes from reflog's retention period.
>>
>> But that doesn't answer the basic question as to why it's ok
>> to trash data that the user explicitly asked git to save?
>
> If the user really asked git to save the changes, she would have
> _committed_ them.
>
> "git stash" really is only about shelving quickly and dirtily something
> you'll need (or maybe need) in a moment.
>
> If you need something from the stash a day after stashing it, you have a
> serious problem with understanding what branches are for.

Even if everyone were to eventually agree with this, I think it's a bit rude
to teach people who stored something important in a stash for a month that
this is the case by deleting their work.

Even with the documentation update, if you're a newbie, you might not know
that git in some places automatically calls git gc when you git pull, as in
the example Brandon gave.

-- 
Mikael Magnusson

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

[Brandon Casey]

Junio C Hamano wrote:
> Wincent Colaiuta <win@wincent.com> writes:
> 
>> 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.
> 
> Yes, but for a limited amount of time.

The fact that this caveat is not mentioned anywhere in the stash
documentation or anywhere in the commit log related to git-stash.sh makes
me think that this idea of 'a limited amount of time' was possibly not a
design decision but merely a side effect of stashes being implemented using the
reflog. Of course I didn't pay any attention to the discussions about stash
back when it was implemented, so I may definitely be wrong.

I'm not sure what the drawback is for persistent stashes though. This is
what I can think of:

  - enlarges repository size by retaining cruft referenced by old stashes
  - encourages bad workflows
  - behaves in a way that is not expected or preferred by the user
  - overly complicates code

The first item I think is somewhat irrelevant. There are many ways that a user
could cause repository size growth, and as Wincent suggested, the increase in
size of the list of stashes is an incentive to clean it up. And in the case of
user generated data, the definition of cruft should be left to the user.

I don't think the second item is true. I don't think any particular work flow
is being encouraged here.

The third item is the one I think is the most important. I think this is a user
interface issue. "Does git do what the user _expects_ git to do?". I offered one
example where the current behavior would produce a result that was likely not
expected by the user and possibly not desired by the user. I think a counter
example (one that would argue against the suggested change in behavior), is if
it were true that if I were to create a stash today, and then be surprised 30
days from now when I do a 'stash list' and find the stash is still there.
Something along the lines of:

   $ git stash save my work
   # wait 30 days
   $ git stash list
   stash@{0}: WIP on master: my work

   # and if my reaction were something like:
   # hmm, that's strange, what is that stash still doing there? It's been 30 days,
   # it should be gone.

btw, that _is_ the current behavior if 'reflog expire' hasn't been run yet for
some reason. Someone who only allows the auto gc to clean their repository would'nt
know any difference.

-brandon

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

[Junio C Hamano]

Brandon Casey <casey@nrlssc.navy.mil> writes:

> The fact that this caveat is not mentioned anywhere in the stash
> documentation or anywhere in the commit log related to git-stash.sh makes
> me think that this idea of 'a limited amount of time' was possibly not a
> design decision but merely a side effect of stashes being implemented using the
> reflog. Of course I didn't pay any attention to the discussions about stash
> back when it was implemented, so I may definitely be wrong.

I do not deeply care either way, but perhaps

 http://thread.gmane.org/gmane.comp.version-control.git/50737/focus=50863 

and yes use of reflog was more or less conscious thing and the mechanism
is very much temporary in nature (see the use case stated in the starting
thread).

> it were true that if I were to create a stash today, and then be surprised 30
> days from now when I do a 'stash list' and find the stash is still there.
> Something along the lines of:
>
>    $ git stash save my work
>    # wait 30 days
>    $ git stash list
>    stash@{0}: WIP on master: my work
>
>    # and if my reaction were something like:
>    # hmm, that's strange, what is that stash still doing there? It's been 30 days,
>    # it should be gone.

We could prune before running "git stash list", but why bother?  The fact
you can see it is like a bonus.

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

[Brandon Casey]

Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> The fact that this caveat is not mentioned anywhere in the stash
>> documentation or anywhere in the commit log related to git-stash.sh makes
>> me think that this idea of 'a limited amount of time' was possibly not a
>> design decision but merely a side effect of stashes being implemented using the
>> reflog. Of course I didn't pay any attention to the discussions about stash
>> back when it was implemented, so I may definitely be wrong.
> 
> I do not deeply care either way, but perhaps
> 
>  http://thread.gmane.org/gmane.comp.version-control.git/50737/focus=50863 

Ahh, you reveal that you were not always a supporter of "stash per branch" in
this thread. :)

> and yes use of reflog was more or less conscious thing and the mechanism
> is very much temporary in nature

I see. Thanks for the reference.

> (see the use case stated in the starting
> thread).

Yes, I understand the use case. I am just not convinced that a persistent
stash would be detrimental, but I also do not care deeply.

>> it were true that if I were to create a stash today, and then be surprised 30
>> days from now when I do a 'stash list' and find the stash is still there.
>> Something along the lines of:
>>
>>    $ git stash save my work
>>    # wait 30 days
>>    $ git stash list
>>    stash@{0}: WIP on master: my work
>>
>>    # and if my reaction were something like:
>>    # hmm, that's strange, what is that stash still doing there? It's been 30 days,
>>    # it should be gone.
> 
> We could prune before running "git stash list", but why bother?  The fact
> you can see it is like a bonus.

hmph :)

-brandon

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

[しらいしななこ]

Quoting Junio C Hamano <gitster@pobox.com>: writes:

> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> The fact that this caveat is not mentioned anywhere in the stash
>> documentation or anywhere in the commit log related to git-stash.sh makes
>> me think that this idea of 'a limited amount of time' was possibly not a
>> design decision but merely a side effect of stashes being implemented using the
>> reflog. Of course I didn't pay any attention to the discussions about stash
>> back when it was implemented, so I may definitely be wrong.
>
> I do not deeply care either way, but perhaps
>
>  http://thread.gmane.org/gmane.comp.version-control.git/50737/focus=50863 
>
> and yes use of reflog was more or less conscious thing and the mechanism
> is very much temporary in nature (see the use case stated in the starting
> thread).

After reading the thread, I reread the manual page.

I agree with some people that it would be nicer if the documentation
spelled out the temporary nature of the stashed states better.

-- 8< -- (^_^) -- >8 --

Improved git-stash documentation

The examples in the manual talk temporary operation but it is not a strong
enough hint that the stashed states are temporary in nature and designed
to be automatically pruned away when gc runs.

Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
---

 Documentation/git-stash.txt |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index baa4f55..65f6af7 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -14,10 +14,11 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-Use 'git-stash' when you want to record the current state of the
-working directory and the index, but want to go back to a clean
-working directory.  The command saves your local modifications away
-and reverts the working directory to match the `HEAD` commit.
+`git-stash` records the current state of the work tree and the index, and
+reverts them to the state after freshly checking out the current commit.
+You can temporarily switch to work on something different, and once you
+finished handling the emergency, you can come back to the state before you
+were interrupted.
 
 The modifications stashed away by this command can be listed with
 `git-stash list`, inspected with `git-stash show`, and restored
@@ -84,6 +85,9 @@ longer apply the changes as they were originally).
 clear::
 	Remove all the stashed states. Note that those states will then
 	be subject to pruning, and may be difficult or impossible to recover.
+	Old stashed states are also pruned automatically when
+	linkgit:git-gc[1] prunes old reflog (see linkgit:git-reflog[1])
+	entries.
 
 drop [<stash>]::
 

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Get a free email address with REAL anti-spam protection.
http://www.bluebottle.com/tag/1

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

[Andreas Ericsson]

Wincent Colaiuta wrote:
> 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.

> 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

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

[Jeff King]

On Fri, Jun 13, 2008 at 06:26:28AM +0200, Andreas Ericsson wrote:

> 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.

I think we are getting into circular reasoning here (on both sides):

Branches are better, because they don't expire. Stashes expire, because
branches are a better way to do what you want.

Stashes shouldn't expire, because the user told the stash to save
information. The user considers it a "save" because stashes hold things
forever. Stashes hold things forever because they shouldn't expire.

In other words, yes, the developer who thought of stashes didn't think
they'd be used for a long period of time. That's _why_ they were
designed as they were. The status quo argument says "this is what a
stash is, because that is how it is implemented."

So I would expect people in favor of the change to say "here is why
long-term stashes are useful." And I would expect such an argument to
address the fact that we don't simply want to recreate branches (badly).
In other words, what is the compelling use case that makes people want
to stash for months at a time?

-Peff

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

[Andreas Ericsson]

Jeff King wrote:
> On Fri, Jun 13, 2008 at 06:26:28AM +0200, Andreas Ericsson wrote:
> 
>> 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.
> 
> I think we are getting into circular reasoning here (on both sides):
> 
> Branches are better, because they don't expire. Stashes expire, because
> branches are a better way to do what you want.
> 
> Stashes shouldn't expire, because the user told the stash to save
> information. The user considers it a "save" because stashes hold things
> forever. Stashes hold things forever because they shouldn't expire.
> 
> In other words, yes, the developer who thought of stashes didn't think
> they'd be used for a long period of time. That's _why_ they were
> designed as they were. The status quo argument says "this is what a
> stash is, because that is how it is implemented."
> 
> So I would expect people in favor of the change to say "here is why
> long-term stashes are useful." And I would expect such an argument to
> address the fact that we don't simply want to recreate branches (badly).
> In other words, what is the compelling use case that makes people want
> to stash for months at a time?
> 

Ah right. Thanks for clarifying and putting me back on a useful track.

To me, long-living stashes are useful because I can all of a sudden be
pulled away from something I'm working on and set to work on something
entirely different for up to 6 months (so far we haven't had a single
emergency project run longer than that). It doesn't happen a lot, but
it *does* happen.

When that happens, I just leave everything as-is, because that's the
most useful state for me to find it in and serves as a nice bump to jog
my memory as to precisely it was I was working on. When I get back it's
possible that someone else has committed design changes or some minor
bugfixes, so naturally I always fetch to make sure I inspect the latest
changes.

I sometimes have stashes around for a day or two if it turns out I
absolutely have to fix some bug or add something to an API before I
can finish the feature I just started working on and the minor change
turns out to be not-so-minor (or if it requires a day or two of testing
to verify).

Sure, I could probably benefit from starting a topic-branch immediately
and then rebase it later, but I also have a git-daemon running so my
co-workers can fetch the latest from me (I work with back-end stuff
usually, and sometimes they need mockups of soon-to-be-real API stuff
which we'd prefer not to get into the central repository), and I don't
want them to get the stuff I *know* is incomplete. It leads to confusion
and unnecessary work. Stashes are handy there.

This workflow works fine for me, but I'd be appalled if I all of a sudden
got back from a period of being away, did a git-fetch and had git-gc
remove my stash(es). I rarely have more than one or two.

Come to think of it, I think it has actually happened once, and I spent
two days trying to find the changes I knew I had made before I gave up
and wrote it down to the changes having been done on a testing system
and overwritten at a later time.

I think these are the options we're faced with:
1. Never expire stashes (don't shoot the user)
2. Don't treat stashes specially (shoot the user)
3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)
4. Make the behaviour configurable (let the users shoot themselves)
5. Double the expiration time on stashes and warn for them when they should
   normally have expired (during gc, that is) (shoot the user, but warn first).

I'm all for #4 and will cook up a patch for that next week when I'm on
vacation unless #1 gets applied before that.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Jeff King]

On Fri, Jun 13, 2008 at 09:16:42AM +0200, Andreas Ericsson wrote:

> To me, long-living stashes are useful because I can all of a sudden be
> pulled away from something I'm working on and set to work on something
> entirely different for up to 6 months (so far we haven't had a single
> emergency project run longer than that). It doesn't happen a lot, but
> it *does* happen.

So of course my first question is "then why didn't you use a branch?" :)

I'm not, by the way, trying to say "there is no good reason not to use a
branch." I am trying to figure out what the reasons are, because I
wonder if there is a more useful abstraction we can come up for handling
this situation.

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).

For '1', I guess the only solution would be some way of making a topic
branch easy to stash and restore. And that would end up looking quite a
bit like stash; I would think the interface would be "git notstash
branchname". Which we sort of have with "git stash save <message>"
already. We could say "if you didn't provide a message, then it will be
gc'ed eventually, but if you did, then it lives forever". That would
work fine for my workflow (I don't bother naming stashes, since I
generally unstash them immediately). But it seems like an accident
waiting to happen for unsuspecting users.

> I think these are the options we're faced with:
> 1. Never expire stashes (don't shoot the user)
> 2. Don't treat stashes specially (shoot the user)
> 3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)
> 4. Make the behaviour configurable (let the users shoot themselves)
> 5. Double the expiration time on stashes and warn for them when they should
>   normally have expired (during gc, that is) (shoot the user, but warn first).

I am tempted by #3, which again matches my workflow. But again, it seems
like an accident waiting to happen for unsuspecting users.

So I think either #1 or #4 is reasonable. #4 probably isn't worth the
effort. If the stash reflog gets too cluttered, one can always expire or
clean it manually.

-Peff

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

[Andreas Ericsson]

Jeff King wrote:
> On Fri, Jun 13, 2008 at 09:16:42AM +0200, Andreas Ericsson wrote:
> 
>> To me, long-living stashes are useful because I can all of a sudden be
>> pulled away from something I'm working on and set to work on something
>> entirely different for up to 6 months (so far we haven't had a single
>> emergency project run longer than that). It doesn't happen a lot, but
>> it *does* happen.
> 
> So of course my first question is "then why didn't you use a branch?" :)
> 

Because stashes are convenient, never get propagated anywhere by accident,
are easy to apply, means you won't have the hassle of creating "topic-bugs"
and later merge it into "topic" when you find something you need to fix
before you merge "topic" into "master". There are lots of good reasons.

> 
>> I think these are the options we're faced with:
>> 1. Never expire stashes (don't shoot the user)
>> 2. Don't treat stashes specially (shoot the user)
>> 3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)
>> 4. Make the behaviour configurable (let the users shoot themselves)
>> 5. Double the expiration time on stashes and warn for them when they should
>>   normally have expired (during gc, that is) (shoot the user, but warn first).
> 
> I am tempted by #3, which again matches my workflow. But again, it seems
> like an accident waiting to happen for unsuspecting users.
> 
> So I think either #1 or #4 is reasonable. #4 probably isn't worth the
> effort. If the stash reflog gets too cluttered, one can always expire or
> clean it manually.
> 

Right. If #1 gets dropped, I'll most likely hack up #4 though. I'd hate
for one part of git to be able to silently drop work when every other
aspect of it makes damn sure that never, ever happens.

I can imagine lots of people complaining if the merge logic suddenly
starts clobbering dirty work-tree files with an mtime 90 days in the past,
even though the user hasn't explicitly asked git to take care of those at
all.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Jakub Narebski]

Jeff King <peff@peff.net> writes:

> So of course my first question is "then why didn't you use a branch?" :)
> 
> I'm not, by the way, trying to say "there is no good reason not to use a
> branch." I am trying to figure out what the reasons are, because I
> wonder if there is a more useful abstraction we can come up for handling
> this situation.
> 
> 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).
[...]

There is one thing that is easy to do with a stash (due to the way it
is implemented, even if it complicates it a bit), and you CANNOT do
(without much hassle) with branches, namely saving state where _index_
state matters, either partial commit (or just added files), or
conflict resolve in progress.

I'm not sure how useful such a thing can be after a month, but if
project has slow rate of development (and developer can deal with such
"ahlfway" state decently when restored), it can happen...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Sverre Rabbelier]

On Fri, Jun 13, 2008 at 9:42 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Jun 13, 2008 at 09:16:42AM +0200, Andreas Ericsson wrote:
>> To me, long-living stashes are useful because I can all of a sudden be
>> pulled away from something I'm working on and set to work on something
>> entirely different for up to 6 months (so far we haven't had a single
>> emergency project run longer than that). It doesn't happen a lot, but
>> it *does* happen.
>
> So of course my first question is "then why didn't you use a branch?" :)

Because nobody / not everybody has perfect foresight, sometimes you
don't know in advance that what you thought was going to be a
temporary stash will turn into a long lived stash. What you are saying
is that really you should always create a branch, just in case your
temporary stash proved to be more long-lived than thought?


-- 
Cheers,

Sverre Rabbelier

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

[Jeff King]

On Fri, Jun 13, 2008 at 10:56:56AM +0200, Sverre Rabbelier wrote:

> > So of course my first question is "then why didn't you use a branch?" :)
> 
> Because nobody / not everybody has perfect foresight, sometimes you
> don't know in advance that what you thought was going to be a
> temporary stash will turn into a long lived stash. What you are saying
> is that really you should always create a branch, just in case your
> temporary stash proved to be more long-lived than thought?

Well, two things here:

  1. I was being somewhat tounge in cheek with that comment. If you read
     the rest of the email, I was trying to figure out reasons why
     people are using "git stash" for long-term storage, to see if we
     could improve the branch interface or find a middle ground between
     temporary stashes and branches.

  2. You don't need perfect foresight. Sometime in the thirty days (but
     probably about 5 minutes later) you realize "oh, this is some
     stashed work that I'm not going to deal with for a while" and you
     promote it to a topic branch.

     But then, I have good reason to want works-in-progress to become
     topic branches: I can then push them to a location which is backed
     up, and from which I can retrieve them if I want to access them
     from a different machine. Not everybody uses the same workflow.
     If you don't see any other benefits to topic branches, then the
     promotion is just a pain.

-Peff

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

[Miles Bader]

Jeff King <peff@peff.net> writes:
>   2. You don't need perfect foresight. Sometime in the thirty days (but
>      probably about 5 minutes later) you realize "oh, this is some
>      stashed work that I'm not going to deal with for a while" and you
>      promote it to a topic branch.

That's exactly the sort of thing that people end up forgetting to do,
even if they know they know about and understand the issue -- and of
course many (most?) people will be using stashes _without_ knowing about
this issue.  I suspect both types will be pretty annoyed when they
realize their work disappeared...

-Miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

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

[Junio C Hamano]

Jeff King <peff@peff.net> 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?

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

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> 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

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

[Sverre Rabbelier]

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. 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

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

[Olivier Marin]

Sverre Rabbelier a écrit :
> 
>  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.

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

[Junio C Hamano]

"Sverre Rabbelier" <alturin@gmail.com> writes:

> 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 ;-)

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

[Wincent Colaiuta]

El 13/6/2008, a las 21:21, Junio C Hamano escribió:

> 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.


Judging from the number of people who have chimed in on this thread  
saying "I expect Git to remember what I told it to remember" indicates  
that all too few think of the stash as being like "/tmp" or a logfile.  
There are two problems:

1) the name of the command, "stash" (and worse still "stash _save_")  
is giving people a misleading impression about what it does

2) the documentation isn't clear enough about what the command does,  
or people don't read it

I suspect that no matter how good the documentation is, a command  
called "git stash save" that remembers stuff only temporarily will  
continue to evoke reactions of puzzlement for as long as it works that  
way. Seeing as Git is usually extremely conservative about throwing  
away people's stuff, the ephemeralness of "git stash" backing store is  
likely to be quite surprising for many.

What are the options?

- improve the documentation

- rename the command (can't see that happening)

- change the behaviour to "keep" until popped/cleared

I think the latter's the best, and a patch for it was already posted  
at the beginning of this thread.

Cheers,
Wincent

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

[Brandon Casey]

Junio C Hamano wrote:

> 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.

I like my analogy better. :)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index baa4f55..119117e 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -17,7 +17,11 @@ DESCRIPTION
 Use 'git-stash' when you want to record the current state of the
 working directory and the index, but want to go back to a clean
 working directory.  The command saves your local modifications away
-and reverts the working directory to match the `HEAD` commit.
+and reverts the working directory to match the `HEAD` commit. You should
+think of the stash like a garbage can in which you place your temporary
+work and then bring out to the curb. If you are quick to use your stashed
+changes you can get them before garbage collection occurs (it's every
+Tuesday where I live, but git does it every 30 days).
 
 The modifications stashed away by this command can be listed with
 `git-stash list`, inspected with `git-stash show`, and restored

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

[Olivier Marin]

Junio C Hamano a écrit :
> 
> 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.

Are you sure about the "temporary" thing? I'm not a native speaker but all
the dictionary I tried, define stash as:

  "to put or hide away (money, valuables, etc.) in a secret or safe place,
   as for future use."

Are they all wrong?

> 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, [...]

Why not encouraging the usage of "pop" then?

Olivier.

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

[しらいしななこ]

Quoting Junio C Hamano <gitster@pobox.com>:

> 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 think I am primarily responsible for this auto expiration
behavior of git-stash command.  The original use case that led
to my git-save script was only about very short-term use.  To
tell you the truth, I did not even realize myself that I can use
stash@{<<number>>} to refer to more than one states until
Johannes Schindelin pointed it out to me.  It was only about
saving the current state once, and that proves it was about very
short-term use and nothing else.

But I think git-stash may have outgrown the original motivation.

Configurable expiration period per reflog like you suggested
sounds like the most sane solution to the issue to me.  I think
that approach is especially attractive because it can kill a few
birds with the same stone.  You can configure remote tracking
branches' logs to expire much sooner than your own branches'
ones, for example.

But I think "reflog.refs/stash.expire" you mentioned above is a
bad name.  Because the default expiration period is configured
with "gc.reflogexpire", it would be better to make the variable
name start with "gc".

By the way, I sent a documentation patch to git-stash but did
not hear any response.  Was there anything wrong with it?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com/tag/3

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

[Wincent Colaiuta]

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

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

[Jeff King]

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

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

[Olivier Marin]

Junio C Hamano a écrit :
> 
>  * 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.

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

[Jon Loeliger]

Andreas Ericsson wrote:

> I think these are the options we're faced with:
> 1. Never expire stashes (don't shoot the user)
> 2. Don't treat stashes specially (shoot the user)
> 3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)
> 4. Make the behaviour configurable (let the users shoot themselves)
> 5. Double the expiration time on stashes and warn for them when they should
>   normally have expired (during gc, that is) (shoot the user, but warn 
> first).
> 
> I'm all for #4 and will cook up a patch for that next week when I'm on
> vacation unless #1 gets applied before that.
> 

There are additional choices too, I think, with config-driven
variations as well.

At git-gc time, notice a reflog entry for a stash that
is about to expire and either convert it to a branch or
interactively offer to convert it or delete it.

Provide a command that converts stash entries to branches.
Maybe even take over refs/stash/ name-space or so?

All with various config options to do that quietly, interactively,
always, never, etc.

jdl

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

[Brandon Casey]

Jeff King wrote:
> On Fri, Jun 13, 2008 at 06:26:28AM +0200, Andreas Ericsson wrote:

> Stashes shouldn't expire, because the user told the stash to save
> information. The user considers it a "save" because stashes hold things
> forever. Stashes hold things forever because they shouldn't expire.

Maybe the command name is the problem. We know that 'git stash' is short
for 'git stash save', so we think we are directing git to "save" something.
In the physical world when I "save" something or "stash" it away, even
temporarilly, I don't stick it in a garbage can and put it out by the curb. :)

Sorry, that's just what popped into my head :)

-brandon

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

[Brandon Casey]

Jeff King wrote:
> On Wed, Jun 11, 2008 at 10:44:17PM +0100, Johannes Schindelin wrote:
> 
>> FWIW I thought it was one of the clever designs of git-stash that it 
>> automatically expires together with the other reflogs.  A stash is only a 
>> temporary thing, that is not even meant to leave the local repository, 
>> after all.
> 
> I agree. If you are concerned about valuable stashes getting deleted, my
> guess is one of:
> 
>   - you would like reflog expiration to be longer
> 
>   - you are using stash as a long-term storage, which it was never
>     intended for. Use a branch.
> 
> The latter, of course, is based on my use and my impression of others
> use (I almost always apply a stash within 30 seconds of having stashed
> it). So maybe everyone is keeping stashes around for months, and this is
> a useful change.

Yes, I think usually stashes are used for very short term storage. At the
same time, I don't expect a stash (however old) to disappear without me
explicitly deleting it.

In particular, I don't want to experience this:

$ git stash list
stash@{0}: WIP on master: 8c372fb... git-cvsimport: do not fail when CVS is /
$ git pull
$ git stash apply
fatal: Needed a single revision
: no valid stashed state found

This would not _surprise_ me since I understand how stashes are implemented
_and_ that git-pull could cause git-gc to run which runs 'git-reflog expire'
which may remove entries from the stash reflog, but it is probably not
expected by most users and it would still irritate me if it did happen.

-brandon

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

[Jeff King]

On Wed, Jun 11, 2008 at 06:25:23PM -0500, Brandon Casey wrote:

> Yes, I think usually stashes are used for very short term storage. At the
> same time, I don't expect a stash (however old) to disappear without me
> explicitly deleting it.
> 
> In particular, I don't want to experience this:
> 
> $ git stash list
> stash@{0}: WIP on master: 8c372fb... git-cvsimport: do not fail when CVS is /
> $ git pull
> $ git stash apply
> fatal: Needed a single revision
> : no valid stashed state found

Did that actually happen to you? Because it seems kind of unlikely to me
that you would perform this exact sequence of events, _exactly_ 90 days
after stashing (i.e., the 90 day period expires sometime between "git
stash list" and "git pull"). Not to mention that you actually _care_
about the stash 90 days later.

So yes, I would hate for that to happen, too. However, I think there is
a real benefit to garbage collecting stashes, and the scenario you
describe seems implausibly unlikely.

-Peff

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

[Brandon Casey]

Jeff King wrote:
> On Wed, Jun 11, 2008 at 06:25:23PM -0500, Brandon Casey wrote:
> 
>> Yes, I think usually stashes are used for very short term storage. At the
>> same time, I don't expect a stash (however old) to disappear without me
>> explicitly deleting it.
>>
>> In particular, I don't want to experience this:
>>
>> $ git stash list
>> stash@{0}: WIP on master: 8c372fb... git-cvsimport: do not fail when CVS is /
>> $ git pull
>> $ git stash apply
>> fatal: Needed a single revision
>> : no valid stashed state found
> 
> Did that actually happen to you?

It has happened and that is what brought it to my attention. But I don't
remember whether I was testing reflog or gc, or whether they had reached
the expiration date naturally or not. The stashes that were lost were
not important, so the incident was enough to put the idea in the back of
my mind, but not enough for me to yell and scream. Maybe that's proof that
persistent stashes are unnecessary?, I don't know.

> Because it seems kind of unlikely to me
> that you would perform this exact sequence of events, _exactly_ 90 days
> after stashing (i.e., the 90 day period expires sometime between "git
> stash list" and "git pull"). Not to mention that you actually _care_
> about the stash 90 days later.

Wouldn't it usually be 30 days? Wouldn't stash objects generally be unreachable?

Also, the sequence above would not have to be performed _exactly_ at the
expiration date. The listing of the stashes i.e. git-log, does not perform
reflog expiration AFAIK. So the initial 'stash list' and the 'git pull' do
not have to straddle the expiration date, they can all be performed any time
after the expiration point to produce the above behavior.

> So yes, I would hate for that to happen, too. However, I think there is
> a real benefit to garbage collecting stashes, and the scenario you
> describe seems implausibly unlikely.

I really hate special cases, so special casing stashes is something I was
reluctant to do. At the same time I see stashes as something very different
from reflogs even though stashes are implemented using reflogs. The big
difference is that reflogs are created automatically and stashes are created
by explicit user action. Automatically deleting something that git creates
automatically is ok and desirable, doing so for something the user explicitly
created is not necessarily so.

Now that I have read some of my email, I see that this conversation has been
continued without me and this same point has already been made much more
elikwintlee by Wincent Colaiuta.

-brandon

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

[Jeff King]

On Thu, Jun 12, 2008 at 11:46:34AM -0500, Brandon Casey wrote:

> > stash list" and "git pull"). Not to mention that you actually _care_
> > about the stash 90 days later.
> 
> Wouldn't it usually be 30 days? Wouldn't stash objects generally be
> unreachable?

Yes, sorry, I was looking at the wrong config value.

> Also, the sequence above would not have to be performed _exactly_ at the
> expiration date. The listing of the stashes i.e. git-log, does not perform
> reflog expiration AFAIK. So the initial 'stash list' and the 'git pull' do
> not have to straddle the expiration date, they can all be performed any time
> after the expiration point to produce the above behavior.

No, but it would have to be performed _after_ the expiration, but
_before_ any auto-gc happened. So it is a smaller window than "anytime
after expiration" but not as small as a particular 30-second window.

> from reflogs even though stashes are implemented using reflogs. The big
> difference is that reflogs are created automatically and stashes are created
> by explicit user action. Automatically deleting something that git creates
> automatically is ok and desirable, doing so for something the user explicitly
> created is not necessarily so.

Wincent made this same argument. I don't really agree with it. It is
predicated on the assumption that stashing something _is_ asking for git
to remember it. My mental model of stashing is that it hasn't been saved
at all, but is rather a convenient way of naming and storing a set of
changes for a second while I do something else.  I think of it in the
same way as a register in vi: I can yank text into it for pasting
after a few commands. But I don't expect yanked text to be stored in the
register a month later.

So I think we are disagreeing not on how stashes should expire, but
rather on what a stash _is_, and what it is useful for. And I am open to
arguments that stashes are useful for longer-term storage. But I also
find the expiration behavior useful (I seem to have accumulated some
cruft in my stash list, and I expect git to clean it out during a gc,
rather than me having to clean it manually). So personally, I would not
be in favor of removing the expiration unless I saw evidence that the
utility of keeping stashes long-term outweighed the benefit of cleaning.

And that evidence is probably "here is a workflow I find useful, and
here is why it is better than any other way of doing it in git" (and
maybe the "better" is simply "new users are going to jump on this way of
using stash, even though it was not as intended").

-Peff

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

[Wincent Colaiuta]

El 13/6/2008, a las 7:48, Jeff King escribió:

> On Thu, Jun 12, 2008 at 11:46:34AM -0500, Brandon Casey wrote:
>
>>
>> from reflogs even though stashes are implemented using reflogs. The  
>> big
>> difference is that reflogs are created automatically and stashes  
>> are created
>> by explicit user action. Automatically deleting something that git  
>> creates
>> automatically is ok and desirable, doing so for something the user  
>> explicitly
>> created is not necessarily so.
>
> Wincent made this same argument. I don't really agree with it. It is
> predicated on the assumption that stashing something _is_ asking for  
> git
> to remember it.

For me it is quite clear that stashing something _is_ asking for Git  
to remember it. It's an explicit user action. It's a request to  
remember something. Whether or not this is actually the best tool for  
the job of long-term storage is much less important than the fact that  
the user explicitly requested it. IMO this trumps all other factors.  
Just because "stash" sounds quicker than "commit" doesn't make it any  
less of an instruction to Git to store something.

Wincent

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

[Sverre Rabbelier]

On Fri, Jun 13, 2008 at 10:41 AM, Wincent Colaiuta <win@wincent.com> wrote:
> El 13/6/2008, a las 7:48, Jeff King escribió:
>> On Thu, Jun 12, 2008 at 11:46:34AM -0500, Brandon Casey wrote:
>>> from reflogs even though stashes are implemented using reflogs.
>>> The big difference is that reflogs are created automatically and
>>> stashes are created by explicit user action. Automatically deleting
>>> something that git creates automatically is ok and desirable, doing
>>> so for something the user explicitly created is not necessarily so.
>>
>> Wincent made this same argument. I don't really agree with it. It is
>> predicated on the assumption that stashing something _is_ asking
>> for git to remember it.

An assumption I agree with:
Use git-stash when you want to record the current state of the working
directory and the index, but want to go back to a clean working
directory. The command saves your local modifications away and reverts
the working directory to match the HEAD commit.

Note the "saves your local modifications", which is, to me, the same
as "please do remember this until I tell you to forget it".

> For me it is quite clear that stashing something _is_ asking for Git to
> remember it. It's an explicit user action. It's a request to remember
> something. Whether or not this is actually the best tool for the job of
> long-term storage is much less important than the fact that the user
> explicitly requested it. IMO this trumps all other factors. Just because
> "stash" sounds quicker than "commit" doesn't make it any less of an
> instruction to Git to store something.

I agree fully with what Wincent is saying, stashes have an explicit
way of cleaning them up:
    Remove all the stashed states. Note that those states will then be
subject to pruning, and may be difficult or impossible to recover.
To me this suggests that otherwise stashes will _not_ be subject to
pruning, which is exactly what this patch does, it makes sure that
stashes are not subject to pruning unless you 'git stash clear' first.

-- 
Cheers,

Sverre Rabbelier

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

[Teemu Likonen]

Sverre Rabbelier wrote (2008-06-13 10:53 +0200):

> On Fri, Jun 13, 2008 at 10:41 AM, Wincent Colaiuta <win@wincent.com>
> wrote:
> 
> > For me it is quite clear that stashing something _is_ asking for Git
> > to remember it. It's an explicit user action. It's a request to
> > remember something. Whether or not this is actually the best tool
> > for the job of long-term storage is much less important than the
> > fact that the user explicitly requested it.
[...]
> I agree fully with what Wincent is saying, stashes have an explicit
> way of cleaning them up:

I agree too. I didn't even know that stashes are currently expired
automatically. I don't use them that much but I'd expect that what
I explicitly ask to save stays there until I decide otherwise.

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

[Jeff King]

On Fri, Jun 13, 2008 at 10:41:42AM +0200, Wincent Colaiuta wrote:

> For me it is quite clear that stashing something _is_ asking for Git to 
> remember it. It's an explicit user action. It's a request to remember 
> something. Whether or not this is actually the best tool for the job of 
> long-term storage is much less important than the fact that the user 
> explicitly requested it. IMO this trumps all other factors. Just because 
> "stash" sounds quicker than "commit" doesn't make it any less of an 
> instruction to Git to store something.

I think you missed the point of my email. I understand that it is clear
to you that you are asking for permanent storage. However, it is equally
clear to me (and to people involved in the design of git stash) that you
are not asking for permanent storage, because that is not what git stash
does.

In other words, we are both proceeding from impressions of what the tool
is meant to do, and what we are asking it to do.

If you are making the argument that new users will be confused, that the
documentation is insufficient, or that this is inconsistent with other
aspects of git's interface, then those are good reasons to argue what
stash _should_ do.

That being said, see the exchanges between Andreas and myself elsewhere
in the thread. I think there is a reasonable argument that "git stash"
_is_ useful for long term storage, and that one way we can support that
is removing the expiration.

So while I prefer the expiration behavior, I think it is reasonable to
sacrifice that to help adapt the tool for a different workflow.

-Peff

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

[Miles Bader]

Jeff King <peff@peff.net> writes:
> So I think we are disagreeing not on how stashes should expire, but
> rather on what a stash _is_, and what it is useful for. And I am open to
> arguments that stashes are useful for longer-term storage. But I also
> find the expiration behavior useful

I don't think anybody is really arguing that stashes aren't _mostly_
useful for short-term storage.

I think the problem is that _sometimes_ stashes end up sticking around
longer than people suspect, and this is not necessarily planned (or even
intentional).  I've done it -- I'll stash some changes "temporarily" in
a little-used working directory, then end up doing something else and
forgetting to re-apply the stash.  I'll then revisit that working dir a
long time later, wonder where my changes are, poke around a bit, and
find them in the stash; no prob.

-Miles

-- 
80% of success is just showing up.  --Woody Allen

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

[Brandon Casey]

Jeff King wrote:
> On Thu, Jun 12, 2008 at 11:46:34AM -0500, Brandon Casey wrote:

>> Also, the sequence above would not have to be performed _exactly_ at the
>> expiration date. The listing of the stashes i.e. git-log, does not perform
>> reflog expiration AFAIK. So the initial 'stash list' and the 'git pull' do
>> not have to straddle the expiration date, they can all be performed any time
>> after the expiration point to produce the above behavior.
> 
> No, but it would have to be performed _after_ the expiration, but
> _before_ any auto-gc happened. So it is a smaller window than "anytime
> after expiration" but not as small as a particular 30-second window.

Right, that's why I showed the 'git-stash list' which still had the stash entry
before the 'git-pull'.

>> from reflogs even though stashes are implemented using reflogs. The big
>> difference is that reflogs are created automatically and stashes are created
>> by explicit user action. Automatically deleting something that git creates
>> automatically is ok and desirable, doing so for something the user explicitly
>> created is not necessarily so.
> 
> Wincent made this same argument. I don't really agree with it. It is
> predicated on the assumption that stashing something _is_ asking for git
> to remember it. My mental model of stashing is that it hasn't been saved
> at all, but is rather a convenient way of naming and storing a set of
> changes for a second while I do something else.  I think of it in the
> same way as a register in vi: I can yank text into it for pasting
> after a few commands. But I don't expect yanked text to be stored in the
> register a month later.

Funny you should mentioned that since I had thought of using a similar
example in defense of my point of view. So I offer a question: after how
much time after you have yanked some text into a register in vi do you
expect vi to clear that register?

I work in a linux environment and as such I use vim. It seems vim retains
text yanked to a register even across sessions (terminate vi, start vi, text
is still yanked). I was not aware of this and I didn't expect it (but it is
a welcome feature). I had expected that registers would be cleared when vi
was terminated, but _only_ when vi was terminated. So even if I left a session
running for 2 years, the register with yanked text would not be cleared. And
this is not because I think a certain workflow which requires a 2 year vi
editing session should be encouraged, but just because I told the editor to
do something, and I expect it to continue doing it until I tell it to stop.

There is a difference between git and applications like vi, and that is that
vi has a 'begin' and an 'end. You begin a vi session, you edit some text, you
yank, paste, save, then you terminate the session. So it is easy to think of the
yanks as being tied to the session. Similarly with something like X11 when you
highlight text, you expect it to be there in the copy buffer until other text is
highlighted or until X terminates.

Git does not really have a 'begin' and an 'end'.  Well there is one thing, and
that is a clone operation. Transient objects, including stashes are not copied
to the clone.

> So I think we are disagreeing not on how stashes should expire, but
> rather on what a stash _is_, and what it is useful for. And I am open to
> arguments that stashes are useful for longer-term storage. But I also
> find the expiration behavior useful (I seem to have accumulated some
> cruft in my stash list, and I expect git to clean it out during a gc,
> rather than me having to clean it manually). So personally, I would not
> be in favor of removing the expiration unless I saw evidence that the
> utility of keeping stashes long-term outweighed the benefit of cleaning.
> 
> And that evidence is probably "here is a workflow I find useful, and
> here is why it is better than any other way of doing it in git" (and
> maybe the "better" is simply "new users are going to jump on this way of
> using stash, even though it was not as intended").

I see it as less of a workflow issue than a safety issue, and a user interface
issue. I don't know if there are workflows that would be made possible by
not expiring the stash. I do think the benefit of automatically cleaning
out the stash so it doesn't accumulate old cruft is less important to me
than an intuitive interface and predictable behavior.

-brandon

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

[Jeff King]

On Fri, Jun 13, 2008 at 11:43:42AM -0500, Brandon Casey wrote:

> > No, but it would have to be performed _after_ the expiration, but
> > _before_ any auto-gc happened. So it is a smaller window than "anytime
> > after expiration" but not as small as a particular 30-second window.
> 
> Right, that's why I showed the 'git-stash list' which still had the
> stash entry before the 'git-pull'.

Right, but I meant that you would have to perform the example commands
you gave after the expiration, but before you had done anything that did
an auto-gc. So you could do it at day 31, unless on day 30 you had done
a "git pull".

But somebody else mentioned that they leave cloned working trees sitting
around, and then find them later. So they might truly have done no
commands.

At any rate, I don't think is especially relevant.

> Funny you should mentioned that since I had thought of using a similar
> example in defense of my point of view. So I offer a question: after how
> much time after you have yanked some text into a register in vi do you
> expect vi to clear that register?

After 10 other yanks? ;)

I was referring not to the named registers, but to the unnamed ones.
IOW, I know that vim will keep my registers from session to session. But
when I yank, it implicitly goes into "0, and the old "0 bumps to "1, "1
to "2, and so forth. "9 is thrown away.

And I think that works pretty well in practice. The size is bounded, but
text stays around long enough for me to use it. And if I want storage
that is guaranteed to last (and I sometimes do), then I use a named
register.

Now here we are bounding by time rather than by number of stashes, but
it is the same concept.

> yanks as being tied to the session. Similarly with something like X11
> when you highlight text, you expect it to be there in the copy buffer
> until other text is highlighted or until X terminates.

Ah, if only that was how X cut buffers actually worked. ;)

> I see it as less of a workflow issue than a safety issue, and a user
> interface issue. I don't know if there are workflows that would be
> made possible by not expiring the stash. I do think the benefit of
> automatically cleaning out the stash so it doesn't accumulate old
> cruft is less important to me than an intuitive interface and
> predictable behavior.

At this point I am inclined to agree. Enough people seem to want to
leave things stashed for long periods that it is a potential hazard to
people who don't know about the expiration. And while I prefer the
expiring cruft behavior, not expiring it isn't _that_ big a deal to me,
compared against the potential for loss.

-Peff

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

[Brandon Casey]

Mike Hommey wrote:
> On Wed, Jun 11, 2008 at 04:29:56PM -0500, Brandon Casey wrote:
>> The stash makes use of git's reflog mechanism, but it is not a reflog
>> in the traditional sense. Each entry is a state that the user explicitly
>> requested git to remember. The stash is generally short-lived, but the
>> user probably expects that a stash will continue to exist until it is
>> explicitly deleted. So we should not expire stash entries.
> 
> I wonder if it wouldn't make sense to have git reflog expire not expire
> stashes *at all*. I mean, you don't necessarily cleanup your repo with
> git gc, and you may end up killing your stashes with git reflog yourself
> if you don't use the "magic" --exclude...

How do you do it cleanly? I don't like the idea of a config option which
must be set by default when a repository is created and I don't really
like the idea of a hard-coded refs/stash in builtin-reflog.c.

git-reflog is currently a generic command. I didn't mind teaching git-gc
about stashes, but to a quasi-plumbing command like git-reflog it doesn't
seem right.

-brandon