{"thread":{"id":"13904","subject":"[PATCH 2/2] git-gc: skip stashes when expiring reflogs","startedAt":"2008-06-11T21:29:56Z","lastAt":"2008-06-18T18:58:29Z","messageCount":69,"participants":["Brandon Casey","Mike Hommey","Johannes Schindelin","Jeff King","Nicolas Pitre","Eric Raible","Wincent Colaiuta","Junio C Hamano","しらいしななこ","Andreas Ericsson","Jakub Narebski","Sverre Rabbelier","Teemu Likonen","Miles Bader","Mikael Magnusson","Jon Loeliger","Olivier Marin","Christian Jaeger"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"79506","messageId":"5vuJsx6Kidj7e8EABk_d63dLAYuWF-S880RrJKu83cJo_ejU3VN-VA@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"OLvkESB0JjBNs9kF8Q2M5UFNBJqq4FjbgGeQVyWstGwcXqCOq16_oomM0y-utOBbV7BnndyrICE@cipher.nrlssc.navy.mil","subject":"[PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-11T21:29:56Z","receivedAt":"2008-06-11T21:29:56Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"The stash makes use of git's reflog mechanism, but it is not a reflog\nin the traditional sense. Each entry is a state that the user explicitly\nrequested git to remember. The stash is generally short-lived, but the\nuser probably expects that a stash will continue to exist until it is\nexplicitly deleted. So we should not expire stash entries.\n\nSigned-off-by: Brandon Casey \n---\n builtin-gc.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-gc.c b/builtin-gc.c\nindex f5625bb..5cb74ec 100644\n--- a/builtin-gc.c\n+++ b/builtin-gc.c\n@@ -30,7 +30,7 @@ static char *prune_expire = \"2.weeks.ago\";\n \n #define MAX_ADD 10\n static const char *argv_pack_refs[] = {\"pack-refs\", \"--all\", \"--prune\", NULL};\n-static const char *argv_reflog[] = {\"reflog\", \"expire\", \"--all\", NULL};\n+static const char *argv_reflog[] = {\"reflog\", \"expire\", \"--all\", \"--exclude=refs/stash\", NULL};\n static const char *argv_repack[MAX_ADD] = {\"repack\", \"-d\", \"-l\", NULL};\n static const char *argv_prune[] = {\"prune\", \"--expire\", NULL, NULL};\n static const char *argv_rerere[] = {\"rerere\", \"gc\", NULL};\n-- \n1.5.5.3\n"},{"id":"79509","messageId":"20080611213648.GA13362@glandium.org","threadId":"13904","inReplyTo":"5vuJsx6Kidj7e8EABk_d63dLAYuWF-S880RrJKu83cJo_ejU3VN-VA@cipher.nrlssc.navy.mil","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-06-11T21:36:48Z","receivedAt":"2008-06-11T21:36:48Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Jun 11, 2008 at 04:29:56PM -0500, Brandon Casey wrote:\n> The stash makes use of git's reflog mechanism, but it is not a reflog\n> in the traditional sense. Each entry is a state that the user explicitly\n> requested git to remember. The stash is generally short-lived, but the\n> user probably expects that a stash will continue to exist until it is\n> explicitly deleted. So we should not expire stash entries.\n\nI wonder if it wouldn't make sense to have git reflog expire not expire\nstashes *at all*. I mean, you don't necessarily cleanup your repo with\ngit gc, and you may end up killing your stashes with git reflog yourself\nif you don't use the \"magic\" --exclude...\n\nMike\n"},{"id":"79511","messageId":"alpine.DEB.1.00.0806112242370.1783@racer","threadId":"13904","inReplyTo":"20080611213648.GA13362@glandium.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-11T21:44:17Z","receivedAt":"2008-06-11T21:44:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Jun 2008, Mike Hommey wrote:\n\n> On Wed, Jun 11, 2008 at 04:29:56PM -0500, Brandon Casey wrote:\n> > The stash makes use of git's reflog mechanism, but it is not a reflog \n> > in the traditional sense. Each entry is a state that the user \n> > explicitly requested git to remember. The stash is generally \n> > short-lived, but the user probably expects that a stash will continue \n> > to exist until it is explicitly deleted. So we should not expire stash \n> > entries.\n> \n> I wonder if it wouldn't make sense to have git reflog expire not expire \n> stashes *at all*. I mean, you don't necessarily cleanup your repo with \n> git gc, and you may end up killing your stashes with git reflog yourself \n> if you don't use the \"magic\" --exclude...\n\nFWIW I thought it was one of the clever designs of git-stash that it \nautomatically expires together with the other reflogs. A stash is only a \ntemporary thing, that is not even meant to leave the local repository, \nafter all.\n\nCiao,\nDscho\n"},{"id":"79516","messageId":"VvvF8m917iheDGmce6GDbHpylrcdO5FHv3p0WaTpMdrLPTsIwooVnQ@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"20080611213648.GA13362@glandium.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-11T22:35:29Z","receivedAt":"2008-06-11T22:35:29Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Mike Hommey wrote:\n> On Wed, Jun 11, 2008 at 04:29:56PM -0500, Brandon Casey wrote:\n>> The stash makes use of git's reflog mechanism, but it is not a reflog\n>> in the traditional sense. Each entry is a state that the user explicitly\n>> requested git to remember. The stash is generally short-lived, but the\n>> user probably expects that a stash will continue to exist until it is\n>> explicitly deleted. So we should not expire stash entries.\n> \n> I wonder if it wouldn't make sense to have git reflog expire not expire\n> stashes *at all*. I mean, you don't necessarily cleanup your repo with\n> git gc, and you may end up killing your stashes with git reflog yourself\n> if you don't use the \"magic\" --exclude...\n\nHow do you do it cleanly? I don't like the idea of a config option which\nmust be set by default when a repository is created and I don't really\nlike the idea of a hard-coded refs/stash in builtin-reflog.c.\n\ngit-reflog is currently a generic command. I didn't mind teaching git-gc\nabout stashes, but to a quasi-plumbing command like git-reflog it doesn't\nseem right.\n\n-brandon\n"},{"id":"79520","messageId":"20080611230344.GD19474@sigill.intra.peff.net","threadId":"13904","inReplyTo":"alpine.DEB.1.00.0806112242370.1783@racer","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-11T23:03:44Z","receivedAt":"2008-06-11T23:03:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 11, 2008 at 10:44:17PM +0100, Johannes Schindelin wrote:\n\n> FWIW I thought it was one of the clever designs of git-stash that it \n> automatically expires together with the other reflogs. A stash is only a \n> temporary thing, that is not even meant to leave the local repository, \n> after all.\n\nI agree. If you are concerned about valuable stashes getting deleted, my\nguess is one of:\n\n - you would like reflog expiration to be longer\n\n - you are using stash as a long-term storage, which it was never\n intended for. Use a branch.\n\nThe latter, of course, is based on my use and my impression of others\nuse (I almost always apply a stash within 30 seconds of having stashed\nit). So maybe everyone is keeping stashes around for months, and this is\na useful change.\n\n-Peff\n"},{"id":"79523","messageId":"alpine.LFD.1.10.0806111918300.23110@xanadu.home","threadId":"13904","inReplyTo":"20080611230344.GD19474@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-06-11T23:21:18Z","receivedAt":"2008-06-11T23:21:18Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 11 Jun 2008, Jeff King wrote:\n\n> I agree. If you are concerned about valuable stashes getting deleted, my\n> guess is one of:\n> \n> - you would like reflog expiration to be longer\n> \n> - you are using stash as a long-term storage, which it was never\n> intended for. Use a branch.\n> \n> The latter, of course, is based on my use and my impression of others\n> use (I almost always apply a stash within 30 seconds of having stashed\n> it). So maybe everyone is keeping stashes around for months, and this is\n> a useful change.\n\nAs you say, branches are there just for that: keeping changes for \nmonths. Stashes are not meant to be used like that nor should we \nencourage it.\n\n\nNicolas\n"},{"id":"79525","messageId":"co7kgJpJNdIs2f8n_PwYKAS7MwV9t1G_P3BPr1eXTZ4ytUHcsPvVaw@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"20080611230344.GD19474@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-11T23:25:23Z","receivedAt":"2008-06-11T23:25:23Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Jeff King wrote:\n> On Wed, Jun 11, 2008 at 10:44:17PM +0100, Johannes Schindelin wrote:\n> \n>> FWIW I thought it was one of the clever designs of git-stash that it \n>> automatically expires together with the other reflogs. A stash is only a \n>> temporary thing, that is not even meant to leave the local repository, \n>> after all.\n> \n> I agree. If you are concerned about valuable stashes getting deleted, my\n> guess is one of:\n> \n> - you would like reflog expiration to be longer\n> \n> - you are using stash as a long-term storage, which it was never\n> intended for. Use a branch.\n> \n> The latter, of course, is based on my use and my impression of others\n> use (I almost always apply a stash within 30 seconds of having stashed\n> it). So maybe everyone is keeping stashes around for months, and this is\n> a useful change.\n\nYes, I think usually stashes are used for very short term storage. At the\nsame time, I don't expect a stash (however old) to disappear without me\nexplicitly deleting it.\n\nIn particular, I don't want to experience this:\n\n$ git stash list\nstash@{0}: WIP on master: 8c372fb... git-cvsimport: do not fail when CVS is /\n$ git pull\n$ git stash apply\nfatal: Needed a single revision\n: no valid stashed state found\n\nThis would not _surprise_ me since I understand how stashes are implemented\n_and_ that git-pull could cause git-gc to run which runs 'git-reflog expire'\nwhich may remove entries from the stash reflog, but it is probably not\nexpected by most users and it would still irritate me if it did happen.\n\n-brandon\n"},{"id":"79537","messageId":"20080612041847.GB24868@sigill.intra.peff.net","threadId":"13904","inReplyTo":"co7kgJpJNdIs2f8n_PwYKAS7MwV9t1G_P3BPr1eXTZ4ytUHcsPvVaw@cipher.nrlssc.navy.mil","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-12T04:18:47Z","receivedAt":"2008-06-12T04:18:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 11, 2008 at 06:25:23PM -0500, Brandon Casey wrote:\n\n> Yes, I think usually stashes are used for very short term storage. At the\n> same time, I don't expect a stash (however old) to disappear without me\n> explicitly deleting it.\n> \n> In particular, I don't want to experience this:\n> \n> $ git stash list\n> stash@{0}: WIP on master: 8c372fb... git-cvsimport: do not fail when CVS is /\n> $ git pull\n> $ git stash apply\n> fatal: Needed a single revision\n> : no valid stashed state found\n\nDid that actually happen to you? Because it seems kind of unlikely to me\nthat you would perform this exact sequence of events, _exactly_ 90 days\nafter stashing (i.e., the 90 day period expires sometime between \"git\nstash list\" and \"git pull\"). Not to mention that you actually _care_\nabout the stash 90 days later.\n\nSo yes, I would hate for that to happen, too. However, I think there is\na real benefit to garbage collecting stashes, and the scenario you\ndescribe seems implausibly unlikely.\n\n-Peff\n"},{"id":"79538","messageId":"loom.20080612T042942-698@post.gmane.org","threadId":"13904","inReplyTo":"alpine.LFD.1.10.0806111918300.23110@xanadu.home","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-06-12T04:32:40Z","receivedAt":"2008-06-12T04:32:40Z","isPatch":true,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Nicolas Pitre cam.org> writes:\n\n> As you say, branches are there just for that: keeping changes for \n> months. Stashes are not meant to be used like that nor should we \n> encourage it.\n\nThis unfortunately goes against the recommended usage in John Wiegley's\notherwise excellent \"Git From the Bottom Up\". I've contacted him separately to\nmake him aware of the collective wisdom of not relying on stashes for long-term\nstorage.\n\n- Eric\n"},{"id":"79558","messageId":"6413041E-A64A-4BF4-9ECF-F7BFA5C1EAEF@wincent.com","threadId":"13904","inReplyTo":"loom.20080612T042942-698@post.gmane.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-12T05:35:43Z","receivedAt":"2008-06-12T05:35:43Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 12/6/2008, a las 6:32, Eric Raible escribió:\n\n> Nicolas Pitre cam.org> writes:\n>\n>> As you say, branches are there just for that: keeping changes for\n>> months. Stashes are not meant to be used like that nor should we\n>> encourage it.\n>\n> This unfortunately goes against the recommended usage in John \n> Wiegley's\n> otherwise excellent \"Git From the Bottom Up\". I've contacted him \n> separately to\n> make him aware of the collective wisdom of not relying on stashes \n> for long-term\n> storage.\n\nYes, we shouldn't _encourage_ people to use stashes as a long-term \nstorage mechanism, but neither should we allow old stashes to silently \ndisappear as a result of reflog expiry, especially as part of \nautomatic garbage collection. There are two reasons:\n\n(1) Normal reflogs accumulate cruft automatically through normal use \nand if not cleaned up they'll just grow and grow and grow. On the \nother hand, for \"git stash\" to accumulate cruft over the long term the \nuser actually has to take action and _abuse_ them. Abuse is less \nlikely because it requires this conscious action, and as the output of \n\"git stash list\" gets bigger and more unwieldy this will serve to \nencourage people to clean out their stashes themselves, or not let the \nlist grow out of control in the first place. In other words, the size \nof the stash reflog is unlikely to be a problem.\n\n(2) Automatically expiring normal reflogs is a service to the user, \nbecause it's cleaning up something that is automatically generated. \nStashes are the result of a concious user decision to create them, so \nautomatically \"cleaning them up\" is _not_ going to help the user.\n\nSo yes, branches _are_ better and more appropriate for long term \nstorage than stashes, but even so I don't think it's right for us to \nrisk throwing away information that the user explicitly stashed and \nexpected Git to look after for them.\n\nWincent\n"},{"id":"79598","messageId":"alpine.LFD.1.10.0806121013430.23110@xanadu.home","threadId":"13904","inReplyTo":"6413041E-A64A-4BF4-9ECF-F7BFA5C1EAEF@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-06-12T14:14:30Z","receivedAt":"2008-06-12T14:14:30Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 12 Jun 2008, Wincent Colaiuta wrote:\n\n> Yes, we shouldn't _encourage_ people to use stashes as a long-term storage\n> mechanism, but neither should we allow old stashes to silently disappear as a\n> result of reflog expiry, especially as part of automatic garbage collection.\n> There are two reasons:\n> \n> (1) Normal reflogs accumulate cruft automatically through normal use and if\n> not cleaned up they'll just grow and grow and grow. On the other hand, for\n> \"git stash\" to accumulate cruft over the long term the user actually has to\n> take action and _abuse_ them. Abuse is less likely because it requires this\n> conscious action, and as the output of \"git stash list\" gets bigger and more\n> unwieldy this will serve to encourage people to clean out their stashes\n> themselves, or not let the list grow out of control in the first place. In\n> other words, the size of the stash reflog is unlikely to be a problem.\n> \n> (2) Automatically expiring normal reflogs is a service to the user, because\n> it's cleaning up something that is automatically generated. Stashes are the\n> result of a concious user decision to create them, so automatically \"cleaning\n> them up\" is _not_ going to help the user.\n> \n> So yes, branches _are_ better and more appropriate for long term storage than\n> stashes, but even so I don't think it's right for us to risk throwing away\n> information that the user explicitly stashed and expected Git to look after\n> for them.\n\nFair enough.\n\n\nNicolas\n"},{"id":"79608","messageId":"u5dYyGz0Q8KNQXnvGOEGmG2BTfT-vJCEFeSUa2I_99Q@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"20080612041847.GB24868@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-12T16:46:34Z","receivedAt":"2008-06-12T16:46:34Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Jeff King wrote:\n> On Wed, Jun 11, 2008 at 06:25:23PM -0500, Brandon Casey wrote:\n> \n>> Yes, I think usually stashes are used for very short term storage. At the\n>> same time, I don't expect a stash (however old) to disappear without me\n>> explicitly deleting it.\n>>\n>> In particular, I don't want to experience this:\n>>\n>> $ git stash list\n>> stash@{0}: WIP on master: 8c372fb... git-cvsimport: do not fail when CVS is /\n>> $ git pull\n>> $ git stash apply\n>> fatal: Needed a single revision\n>> : no valid stashed state found\n> \n> Did that actually happen to you?\n\nIt has happened and that is what brought it to my attention. But I don't\nremember whether I was testing reflog or gc, or whether they had reached\nthe expiration date naturally or not. The stashes that were lost were\nnot important, so the incident was enough to put the idea in the back of\nmy mind, but not enough for me to yell and scream. Maybe that's proof that\npersistent stashes are unnecessary?, I don't know.\n\n> Because it seems kind of unlikely to me\n> that you would perform this exact sequence of events, _exactly_ 90 days\n> after stashing (i.e., the 90 day period expires sometime between \"git\n> stash list\" and \"git pull\"). Not to mention that you actually _care_\n> about the stash 90 days later.\n\nWouldn't it usually be 30 days? Wouldn't stash objects generally be unreachable?\n\nAlso, the sequence above would not have to be performed _exactly_ at the\nexpiration date. The listing of the stashes i.e. git-log, does not perform\nreflog expiration AFAIK. So the initial 'stash list' and the 'git pull' do\nnot have to straddle the expiration date, they can all be performed any time\nafter the expiration point to produce the above behavior.\n\n> So yes, I would hate for that to happen, too. However, I think there is\n> a real benefit to garbage collecting stashes, and the scenario you\n> describe seems implausibly unlikely.\n\nI really hate special cases, so special casing stashes is something I was\nreluctant to do. At the same time I see stashes as something very different\nfrom reflogs even though stashes are implemented using reflogs. The big\ndifference is that reflogs are created automatically and stashes are created\nby explicit user action. Automatically deleting something that git creates\nautomatically is ok and desirable, doing so for something the user explicitly\ncreated is not necessarily so.\n\nNow that I have read some of my email, I see that this conversation has been\ncontinued without me and this same point has already been made much more\nelikwintlee by Wincent Colaiuta.\n\n-brandon\n"},{"id":"79622","messageId":"7vzlpqza0t.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"6413041E-A64A-4BF4-9ECF-F7BFA5C1EAEF@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-12T20:13:54Z","receivedAt":"2008-06-12T20:13:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wincent Colaiuta writes:\n\n> So yes, branches _are_ better and more appropriate for long term \n> storage than stashes, but even so I don't think it's right for us to \n> risk throwing away information that the user explicitly stashed and \n> expected Git to look after for them.\n\nYes, but for a limited amount of time.\n"},{"id":"79629","messageId":"279b37b20806121335p90a6d40qb39b73f71dae990b@mail.gmail.com","threadId":"13904","inReplyTo":"7vzlpqza0t.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-06-12T20:35:10Z","receivedAt":"2008-06-12T20:35:10Z","isPatch":true,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Thu, Jun 12, 2008 at 1:13 PM, Junio C Hamano wrote:\n> Wincent Colaiuta writes:\n>\n>> So yes, branches _are_ better and more appropriate for long term\n>> storage than stashes, but even so I don't think it's right for us to\n>> risk throwing away information that the user explicitly stashed and\n>> expected Git to look after for them.\n>\n> Yes, but for a limited amount of time.\n>\n\nA limited amount of time? Why is that? Can you give a rationale which\nat least addresses Wincent's points?\n\nIt's bad enough that 'git stash clear' drops all pending stashes w/out\nat least echoing them (the way git stash drop does), but what is the\nrationale for having git _ever_ forget information which it was specifically\nrequested to remember?\n\nI know that stash is implemented in terms of reflogs, but that seems\nto me an implementation detail which ought not leak out. Especially\nif that leakage ends up forgetting potentially important data.\n\n- Eric\n"},{"id":"79637","messageId":"7vlk1az8aa.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"279b37b20806121335p90a6d40qb39b73f71dae990b@mail.gmail.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-12T20:51:25Z","receivedAt":"2008-06-12T20:51:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric Raible\" writes:\n\n> On Thu, Jun 12, 2008 at 1:13 PM, Junio C Hamano wrote:\n>> Wincent Colaiuta writes:\n>>\n>>> So yes, branches _are_ better and more appropriate for long term\n>>> storage than stashes, but even so I don't think it's right for us to\n>>> risk throwing away information that the user explicitly stashed and\n>>> expected Git to look after for them.\n>>\n>> Yes, but for a limited amount of time.\n>\n> A limited amount of time? Why is that? Can you give a rationale which\n> at least addresses Wincent's points?\n\nPerhaps\n\n http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670\n\nThe user explicitly asks to stash it for a while, where the definition of\nthe \"while\" comes from reflog's retention period.\n"},{"id":"79640","messageId":"tTKBrUhaELJElLgsC8Wvr60D-bMFtfyvc87q5ZYW35M@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"7vzlpqza0t.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-12T21:27:50Z","receivedAt":"2008-06-12T21:27:50Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Junio C Hamano wrote:\n> Wincent Colaiuta writes:\n> \n>> So yes, branches _are_ better and more appropriate for long term \n>> storage than stashes, but even so I don't think it's right for us to \n>> risk throwing away information that the user explicitly stashed and \n>> expected Git to look after for them.\n> \n> Yes, but for a limited amount of time.\n\nThe fact that this caveat is not mentioned anywhere in the stash\ndocumentation or anywhere in the commit log related to git-stash.sh makes\nme think that this idea of 'a limited amount of time' was possibly not a\ndesign decision but merely a side effect of stashes being implemented using the\nreflog. Of course I didn't pay any attention to the discussions about stash\nback when it was implemented, so I may definitely be wrong.\n\nI'm not sure what the drawback is for persistent stashes though. This is\nwhat I can think of:\n\n - enlarges repository size by retaining cruft referenced by old stashes\n - encourages bad workflows\n - behaves in a way that is not expected or preferred by the user\n - overly complicates code\n\nThe first item I think is somewhat irrelevant. There are many ways that a user\ncould cause repository size growth, and as Wincent suggested, the increase in\nsize of the list of stashes is an incentive to clean it up. And in the case of\nuser generated data, the definition of cruft should be left to the user.\n\nI don't think the second item is true. I don't think any particular work flow\nis being encouraged here.\n\nThe third item is the one I think is the most important. I think this is a user\ninterface issue. \"Does git do what the user _expects_ git to do?\". I offered one\nexample where the current behavior would produce a result that was likely not\nexpected by the user and possibly not desired by the user. I think a counter\nexample (one that would argue against the suggested change in behavior), is if\nit were true that if I were to create a stash today, and then be surprised 30\ndays from now when I do a 'stash list' and find the stash is still there.\nSomething along the lines of:\n\n $ git stash save my work\n # wait 30 days\n $ git stash list\n stash@{0}: WIP on master: my work\n\n # and if my reaction were something like:\n # hmm, that's strange, what is that stash still doing there? It's been 30 days,\n # it should be gone.\n\nbtw, that _is_ the current behavior if 'reflog expire' hasn't been run yet for\nsome reason. Someone who only allows the auto gc to clean their repository would'nt\nknow any difference.\n\n-brandon\n"},{"id":"79642","messageId":"279b37b20806121436w4f09c8f7n1009ef2f77b66f87@mail.gmail.com","threadId":"13904","inReplyTo":"7vlk1az8aa.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-06-12T21:36:58Z","receivedAt":"2008-06-12T21:36:58Z","isPatch":true,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Thu, Jun 12, 2008 at 1:51 PM, Junio C Hamano wrote:\n> Perhaps\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670\n>\n> The user explicitly asks to stash it for a while, where the definition of\n> the \"while\" comes from reflog's retention period.\n\nBut that doesn't answer the basic question as to why it's ok\nto trash data that the user explicitly asked git to save?\n\nThe fact that stash is implemented in terms of reflogs seems irrelevant to me.\nIf stash were implemented via branches and cherry picking would it still be\nnatural to automatically expire them?\n\nAt the very least the man page might want to mention the temporary nature\nof stashes. Better yet when 'git stash' could print that out when creating\nthe stash, eh?\n\n- Eric\n"},{"id":"79643","messageId":"7vhcbyz5pp.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"tTKBrUhaELJElLgsC8Wvr60D-bMFtfyvc87q5ZYW35M@cipher.nrlssc.navy.mil","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-12T21:46:58Z","receivedAt":"2008-06-12T21:46:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey writes:\n\n> The fact that this caveat is not mentioned anywhere in the stash\n> documentation or anywhere in the commit log related to git-stash.sh makes\n> me think that this idea of 'a limited amount of time' was possibly not a\n> design decision but merely a side effect of stashes being implemented using the\n> reflog. Of course I didn't pay any attention to the discussions about stash\n> back when it was implemented, so I may definitely be wrong.\n\nI do not deeply care either way, but perhaps\n\n http://thread.gmane.org/gmane.comp.version-control.git/50737/focus=50863 \n\nand yes use of reflog was more or less conscious thing and the mechanism\nis very much temporary in nature (see the use case stated in the starting\nthread).\n\n> it were true that if I were to create a stash today, and then be surprised 30\n> days from now when I do a 'stash list' and find the stash is still there.\n> Something along the lines of:\n>\n> $ git stash save my work\n> # wait 30 days\n> $ git stash list\n> stash@{0}: WIP on master: my work\n>\n> # and if my reaction were something like:\n> # hmm, that's strange, what is that stash still doing there? It's been 30 days,\n> # it should be gone.\n\nWe could prune before running \"git stash list\", but why bother? The fact\nyou can see it is like a bonus.\n"},{"id":"79646","messageId":"fRW8sBboq1iMWGtwlFUpiDE6HkG2OzTHQ13Xtne_hLyGoZQw04GL7Q@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"7vhcbyz5pp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-12T22:10:36Z","receivedAt":"2008-06-12T22:10:36Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Junio C Hamano wrote:\n> Brandon Casey writes:\n> \n>> The fact that this caveat is not mentioned anywhere in the stash\n>> documentation or anywhere in the commit log related to git-stash.sh makes\n>> me think that this idea of 'a limited amount of time' was possibly not a\n>> design decision but merely a side effect of stashes being implemented using the\n>> reflog. Of course I didn't pay any attention to the discussions about stash\n>> back when it was implemented, so I may definitely be wrong.\n> \n> I do not deeply care either way, but perhaps\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/50737/focus=50863 \n\nAhh, you reveal that you were not always a supporter of \"stash per branch\" in\nthis thread. :)\n\n> and yes use of reflog was more or less conscious thing and the mechanism\n> is very much temporary in nature\n\nI see. Thanks for the reference.\n\n> (see the use case stated in the starting\n> thread).\n\nYes, I understand the use case. I am just not convinced that a persistent\nstash would be detrimental, but I also do not care deeply.\n\n>> it were true that if I were to create a stash today, and then be surprised 30\n>> days from now when I do a 'stash list' and find the stash is still there.\n>> Something along the lines of:\n>>\n>> $ git stash save my work\n>> # wait 30 days\n>> $ git stash list\n>> stash@{0}: WIP on master: my work\n>>\n>> # and if my reaction were something like:\n>> # hmm, that's strange, what is that stash still doing there? It's been 30 days,\n>> # it should be gone.\n> \n> We could prune before running \"git stash list\", but why bother? The fact\n> you can see it is like a bonus.\n\nhmph :)\n\n-brandon\n"},{"id":"79666","messageId":"200806130345.m5D3jjPE011619@mi0.bluebottle.com","threadId":"13904","inReplyTo":"7vhcbyz5pp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2008-06-13T03:45:07Z","receivedAt":"2008-06-13T03:45:07Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano : writes:\n\n> Brandon Casey writes:\n>\n>> The fact that this caveat is not mentioned anywhere in the stash\n>> documentation or anywhere in the commit log related to git-stash.sh makes\n>> me think that this idea of 'a limited amount of time' was possibly not a\n>> design decision but merely a side effect of stashes being implemented using the\n>> reflog. Of course I didn't pay any attention to the discussions about stash\n>> back when it was implemented, so I may definitely be wrong.\n>\n> I do not deeply care either way, but perhaps\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/50737/focus=50863 \n>\n> and yes use of reflog was more or less conscious thing and the mechanism\n> is very much temporary in nature (see the use case stated in the starting\n> thread).\n\nAfter reading the thread, I reread the manual page.\n\nI agree with some people that it would be nicer if the documentation\nspelled out the temporary nature of the stashed states better.\n\n-- 8< -- (^_^) -- >8 --\n\nImproved git-stash documentation\n\nThe examples in the manual talk temporary operation but it is not a strong\nenough hint that the stashed states are temporary in nature and designed\nto be automatically pruned away when gc runs.\n\nSigned-off-by: Nanako Shiraishi \n---\n\n Documentation/git-stash.txt | 12 ++++++++----\n 1 files changed, 8 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt\nindex baa4f55..65f6af7 100644\n--- a/Documentation/git-stash.txt\n+++ b/Documentation/git-stash.txt\n@@ -14,10 +14,11 @@ SYNOPSIS\n DESCRIPTION\n -----------\n \n-Use 'git-stash' when you want to record the current state of the\n-working directory and the index, but want to go back to a clean\n-working directory. The command saves your local modifications away\n-and reverts the working directory to match the `HEAD` commit.\n+`git-stash` records the current state of the work tree and the index, and\n+reverts them to the state after freshly checking out the current commit.\n+You can temporarily switch to work on something different, and once you\n+finished handling the emergency, you can come back to the state before you\n+were interrupted.\n \n The modifications stashed away by this command can be listed with\n `git-stash list`, inspected with `git-stash show`, and restored\n@@ -84,6 +85,9 @@ longer apply the changes as they were originally).\n clear::\n \tRemove all the stashed states. Note that those states will then\n \tbe subject to pruning, and may be difficult or impossible to recover.\n+\tOld stashed states are also pruned automatically when\n+\tlinkgit:git-gc[1] prunes old reflog (see linkgit:git-reflog[1])\n+\tentries.\n \n drop []::\n \n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nGet a free email address with REAL anti-spam protection.\nhttp://www.bluebottle.com/tag/1\n"},{"id":"79668","messageId":"4851F6F4.8000503@op5.se","threadId":"13904","inReplyTo":"6413041E-A64A-4BF4-9ECF-F7BFA5C1EAEF@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-06-13T04:26:28Z","receivedAt":"2008-06-13T04:26:28Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Wincent Colaiuta wrote:\n> El 12/6/2008, a las 6:32, Eric Raible escribió:\n> \n>> Nicolas Pitre cam.org> writes:\n>>\n>>> As you say, branches are there just for that: keeping changes for\n>>> months. Stashes are not meant to be used like that nor should we\n>>> encourage it.\n>>\n>> This unfortunately goes against the recommended usage in John Wiegley's\n>> otherwise excellent \"Git From the Bottom Up\". I've contacted him \n>> separately to\n>> make him aware of the collective wisdom of not relying on stashes for \n>> long-term\n>> storage.\n> \n> Yes, we shouldn't _encourage_ people to use stashes as a long-term \n> storage mechanism, but neither should we allow old stashes to silently \n> disappear as a result of reflog expiry, especially as part of automatic \n> garbage collection. There are two reasons:\n> \n> (1) Normal reflogs accumulate cruft automatically through normal use and \n> if not cleaned up they'll just grow and grow and grow. On the other \n> hand, for \"git stash\" to accumulate cruft over the long term the user \n> actually has to take action and _abuse_ them. Abuse is less likely \n> because it requires this conscious action, and as the output of \"git \n> stash list\" gets bigger and more unwieldy this will serve to encourage \n> people to clean out their stashes themselves, or not let the list grow \n> out of control in the first place. In other words, the size of the stash \n> reflog is unlikely to be a problem.\n> \n> (2) Automatically expiring normal reflogs is a service to the user, \n> because it's cleaning up something that is automatically generated. \n> Stashes are the result of a concious user decision to create them, so \n> automatically \"cleaning them up\" is _not_ going to help the user.\n> \n\nI agree.\n\n> So yes, branches _are_ better and more appropriate for long term storage \n> than stashes, but even so I don't think it's right for us to risk \n> throwing away information that the user explicitly stashed and expected \n> Git to look after for them.\n> \n\nWhy are branches better and more appropriate?\nIs it because the developer who first thought of stashes didn't think they'd\nbe used for any halflong period of time?\nIs it because there are actions you can do on a branch that you can't do on\na stash?\n\nWho's to say what's appropriate and not? If I explicitly tell a system to\nsave something for me I damn well expect it to be around when I ask that\nsame system to load it for me too.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"79671","messageId":"alpine.DEB.1.00.0806130551200.6439@racer","threadId":"13904","inReplyTo":"279b37b20806121436w4f09c8f7n1009ef2f77b66f87@mail.gmail.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-13T04:52:53Z","receivedAt":"2008-06-13T04:52:53Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 12 Jun 2008, Eric Raible wrote:\n\n> On Thu, Jun 12, 2008 at 1:51 PM, Junio C Hamano wrote:\n> > Perhaps\n> >\n> > http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670\n> >\n> > The user explicitly asks to stash it for a while, where the definition of\n> > the \"while\" comes from reflog's retention period.\n> \n> But that doesn't answer the basic question as to why it's ok\n> to trash data that the user explicitly asked git to save?\n\nIf the user really asked git to save the changes, she would have \n_committed_ them.\n\n\"git stash\" really is only about shelving quickly and dirtily something \nyou'll need (or maybe need) in a moment.\n\nIf you need something from the stash a day after stashing it, you have a \nserious problem with understanding what branches are for.\n\nCiao,\nDscho\n"},{"id":"79676","messageId":"20080613054840.GA27122@sigill.intra.peff.net","threadId":"13904","inReplyTo":"u5dYyGz0Q8KNQXnvGOEGmG2BTfT-vJCEFeSUa2I_99Q@cipher.nrlssc.navy.mil","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-13T05:48:40Z","receivedAt":"2008-06-13T05:48:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jun 12, 2008 at 11:46:34AM -0500, Brandon Casey wrote:\n\n> > stash list\" and \"git pull\"). Not to mention that you actually _care_\n> > about the stash 90 days later.\n> \n> Wouldn't it usually be 30 days? Wouldn't stash objects generally be\n> unreachable?\n\nYes, sorry, I was looking at the wrong config value.\n\n> Also, the sequence above would not have to be performed _exactly_ at the\n> expiration date. The listing of the stashes i.e. git-log, does not perform\n> reflog expiration AFAIK. So the initial 'stash list' and the 'git pull' do\n> not have to straddle the expiration date, they can all be performed any time\n> after the expiration point to produce the above behavior.\n\nNo, but it would have to be performed _after_ the expiration, but\n_before_ any auto-gc happened. So it is a smaller window than \"anytime\nafter expiration\" but not as small as a particular 30-second window.\n\n> from reflogs even though stashes are implemented using reflogs. The big\n> difference is that reflogs are created automatically and stashes are created\n> by explicit user action. Automatically deleting something that git creates\n> automatically is ok and desirable, doing so for something the user explicitly\n> created is not necessarily so.\n\nWincent made this same argument. I don't really agree with it. It is\npredicated on the assumption that stashing something _is_ asking for git\nto remember it. My mental model of stashing is that it hasn't been saved\nat all, but is rather a convenient way of naming and storing a set of\nchanges for a second while I do something else. I think of it in the\nsame way as a register in vi: I can yank text into it for pasting\nafter a few commands. But I don't expect yanked text to be stored in the\nregister a month later.\n\nSo I think we are disagreeing not on how stashes should expire, but\nrather on what a stash _is_, and what it is useful for. And I am open to\narguments that stashes are useful for longer-term storage. But I also\nfind the expiration behavior useful (I seem to have accumulated some\ncruft in my stash list, and I expect git to clean it out during a gc,\nrather than me having to clean it manually). So personally, I would not\nbe in favor of removing the expiration unless I saw evidence that the\nutility of keeping stashes long-term outweighed the benefit of cleaning.\n\nAnd that evidence is probably \"here is a workflow I find useful, and\nhere is why it is better than any other way of doing it in git\" (and\nmaybe the \"better\" is simply \"new users are going to jump on this way of\nusing stash, even though it was not as intended\").\n\n-Peff\n"},{"id":"79677","messageId":"20080613055800.GA26768@sigill.intra.peff.net","threadId":"13904","inReplyTo":"4851F6F4.8000503@op5.se","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-13T05:58:00Z","receivedAt":"2008-06-13T05:58:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 13, 2008 at 06:26:28AM +0200, Andreas Ericsson wrote:\n\n> Why are branches better and more appropriate?\n> Is it because the developer who first thought of stashes didn't think they'd\n> be used for any halflong period of time?\n> Is it because there are actions you can do on a branch that you can't do on\n> a stash?\n>\n> Who's to say what's appropriate and not? If I explicitly tell a system to\n> save something for me I damn well expect it to be around when I ask that\n> same system to load it for me too.\n\nI think we are getting into circular reasoning here (on both sides):\n\nBranches are better, because they don't expire. Stashes expire, because\nbranches are a better way to do what you want.\n\nStashes shouldn't expire, because the user told the stash to save\ninformation. The user considers it a \"save\" because stashes hold things\nforever. Stashes hold things forever because they shouldn't expire.\n\nIn other words, yes, the developer who thought of stashes didn't think\nthey'd be used for a long period of time. That's _why_ they were\ndesigned as they were. The status quo argument says \"this is what a\nstash is, because that is how it is implemented.\"\n\nSo I would expect people in favor of the change to say \"here is why\nlong-term stashes are useful.\" And I would expect such an argument to\naddress the fact that we don't simply want to recreate branches (badly).\nIn other words, what is the compelling use case that makes people want\nto stash for months at a time?\n\n-Peff\n"},{"id":"79684","messageId":"48521EDA.5040802@op5.se","threadId":"13904","inReplyTo":"20080613055800.GA26768@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-06-13T07:16:42Z","receivedAt":"2008-06-13T07:16:42Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n> On Fri, Jun 13, 2008 at 06:26:28AM +0200, Andreas Ericsson wrote:\n> \n>> Why are branches better and more appropriate?\n>> Is it because the developer who first thought of stashes didn't think they'd\n>> be used for any halflong period of time?\n>> Is it because there are actions you can do on a branch that you can't do on\n>> a stash?\n>>\n>> Who's to say what's appropriate and not? If I explicitly tell a system to\n>> save something for me I damn well expect it to be around when I ask that\n>> same system to load it for me too.\n> \n> I think we are getting into circular reasoning here (on both sides):\n> \n> Branches are better, because they don't expire. Stashes expire, because\n> branches are a better way to do what you want.\n> \n> Stashes shouldn't expire, because the user told the stash to save\n> information. The user considers it a \"save\" because stashes hold things\n> forever. Stashes hold things forever because they shouldn't expire.\n> \n> In other words, yes, the developer who thought of stashes didn't think\n> they'd be used for a long period of time. That's _why_ they were\n> designed as they were. The status quo argument says \"this is what a\n> stash is, because that is how it is implemented.\"\n> \n> So I would expect people in favor of the change to say \"here is why\n> long-term stashes are useful.\" And I would expect such an argument to\n> address the fact that we don't simply want to recreate branches (badly).\n> In other words, what is the compelling use case that makes people want\n> to stash for months at a time?\n> \n\nAh right. Thanks for clarifying and putting me back on a useful track.\n\nTo me, long-living stashes are useful because I can all of a sudden be\npulled away from something I'm working on and set to work on something\nentirely different for up to 6 months (so far we haven't had a single\nemergency project run longer than that). It doesn't happen a lot, but\nit *does* happen.\n\nWhen that happens, I just leave everything as-is, because that's the\nmost useful state for me to find it in and serves as a nice bump to jog\nmy memory as to precisely it was I was working on. When I get back it's\npossible that someone else has committed design changes or some minor\nbugfixes, so naturally I always fetch to make sure I inspect the latest\nchanges.\n\nI sometimes have stashes around for a day or two if it turns out I\nabsolutely have to fix some bug or add something to an API before I\ncan finish the feature I just started working on and the minor change\nturns out to be not-so-minor (or if it requires a day or two of testing\nto verify).\n\nSure, I could probably benefit from starting a topic-branch immediately\nand then rebase it later, but I also have a git-daemon running so my\nco-workers can fetch the latest from me (I work with back-end stuff\nusually, and sometimes they need mockups of soon-to-be-real API stuff\nwhich we'd prefer not to get into the central repository), and I don't\nwant them to get the stuff I *know* is incomplete. It leads to confusion\nand unnecessary work. Stashes are handy there.\n\nThis workflow works fine for me, but I'd be appalled if I all of a sudden\ngot back from a period of being away, did a git-fetch and had git-gc\nremove my stash(es). I rarely have more than one or two.\n\nCome to think of it, I think it has actually happened once, and I spent\ntwo days trying to find the changes I knew I had made before I gave up\nand wrote it down to the changes having been done on a testing system\nand overwritten at a later time.\n\nI think these are the options we're faced with:\n1. Never expire stashes (don't shoot the user)\n2. Don't treat stashes specially (shoot the user)\n3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)\n4. Make the behaviour configurable (let the users shoot themselves)\n5. Double the expiration time on stashes and warn for them when they should\n normally have expired (during gc, that is) (shoot the user, but warn first).\n\nI'm all for #4 and will cook up a patch for that next week when I'm on\nvacation unless #1 gets applied before that.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"79686","messageId":"20080613074257.GA513@sigill.intra.peff.net","threadId":"13904","inReplyTo":"48521EDA.5040802@op5.se","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-13T07:42:57Z","receivedAt":"2008-06-13T07:42:57Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 13, 2008 at 09:16:42AM +0200, Andreas Ericsson wrote:\n\n> To me, long-living stashes are useful because I can all of a sudden be\n> pulled away from something I'm working on and set to work on something\n> entirely different for up to 6 months (so far we haven't had a single\n> emergency project run longer than that). It doesn't happen a lot, but\n> it *does* happen.\n\nSo of course my first question is \"then why didn't you use a branch?\" :)\n\nI'm not, by the way, trying to say \"there is no good reason not to use a\nbranch.\" I am trying to figure out what the reasons are, because I\nwonder if there is a more useful abstraction we can come up for handling\nthis situation.\n\nReading your (and others') responses, it seems like there are two\nthings:\n\n 1. Stashing is about saying \"save everything about where I am now with\n no hassle\". IOW, it's one command, you don't have to decide what\n goes and what stays, and you can pull it back out with one command.\n And maybe there is a psychological component that you are not ready\n to \"commit\" such a work-in-progress (I am extrapolating here, but I\n know that when I first started with git, I was hesitant to commit\n because of my experience with other systems).\n\n 2. Branches tend to get shared, and you don't want people to see your\n stashes, because they are messy works in progress.\n\nTo deal with '2', I wonder if it would be worth making some branches\ninaccessible to pushing/pulling (either via config, or through a special\nnaming convention).\n\nFor '1', I guess the only solution would be some way of making a topic\nbranch easy to stash and restore. And that would end up looking quite a\nbit like stash; I would think the interface would be \"git notstash\nbranchname\". Which we sort of have with \"git stash save \"\nalready. We could say \"if you didn't provide a message, then it will be\ngc'ed eventually, but if you did, then it lives forever\". That would\nwork fine for my workflow (I don't bother naming stashes, since I\ngenerally unstash them immediately). But it seems like an accident\nwaiting to happen for unsuspecting users.\n\n> I think these are the options we're faced with:\n> 1. Never expire stashes (don't shoot the user)\n> 2. Don't treat stashes specially (shoot the user)\n> 3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)\n> 4. Make the behaviour configurable (let the users shoot themselves)\n> 5. Double the expiration time on stashes and warn for them when they should\n> normally have expired (during gc, that is) (shoot the user, but warn first).\n\nI am tempted by #3, which again matches my workflow. But again, it seems\nlike an accident waiting to happen for unsuspecting users.\n\nSo I think either #1 or #4 is reasonable. #4 probably isn't worth the\neffort. If the stash reflog gets too cluttered, one can always expire or\nclean it manually.\n\n-Peff\n"},{"id":"79688","messageId":"48522BA1.9010702@op5.se","threadId":"13904","inReplyTo":"20080613074257.GA513@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-06-13T08:11:13Z","receivedAt":"2008-06-13T08:11:13Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n> On Fri, Jun 13, 2008 at 09:16:42AM +0200, Andreas Ericsson wrote:\n> \n>> To me, long-living stashes are useful because I can all of a sudden be\n>> pulled away from something I'm working on and set to work on something\n>> entirely different for up to 6 months (so far we haven't had a single\n>> emergency project run longer than that). It doesn't happen a lot, but\n>> it *does* happen.\n> \n> So of course my first question is \"then why didn't you use a branch?\" :)\n> \n\nBecause stashes are convenient, never get propagated anywhere by accident,\nare easy to apply, means you won't have the hassle of creating \"topic-bugs\"\nand later merge it into \"topic\" when you find something you need to fix\nbefore you merge \"topic\" into \"master\". There are lots of good reasons.\n\n> \n>> I think these are the options we're faced with:\n>> 1. Never expire stashes (don't shoot the user)\n>> 2. Don't treat stashes specially (shoot the user)\n>> 3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)\n>> 4. Make the behaviour configurable (let the users shoot themselves)\n>> 5. Double the expiration time on stashes and warn for them when they should\n>> normally have expired (during gc, that is) (shoot the user, but warn first).\n> \n> I am tempted by #3, which again matches my workflow. But again, it seems\n> like an accident waiting to happen for unsuspecting users.\n> \n> So I think either #1 or #4 is reasonable. #4 probably isn't worth the\n> effort. If the stash reflog gets too cluttered, one can always expire or\n> clean it manually.\n> \n\nRight. If #1 gets dropped, I'll most likely hack up #4 though. I'd hate\nfor one part of git to be able to silently drop work when every other\naspect of it makes damn sure that never, ever happens.\n\nI can imagine lots of people complaining if the merge logic suddenly\nstarts clobbering dirty work-tree files with an mtime 90 days in the past,\neven though the user hasn't explicitly asked git to take care of those at\nall.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"79689","messageId":"CA1D4ABE-0B83-44CC-B582-1E85784330AB@wincent.com","threadId":"13904","inReplyTo":"20080613054840.GA27122@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-13T08:41:42Z","receivedAt":"2008-06-13T08:41:42Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 13/6/2008, a las 7:48, Jeff King escribió:\n\n> On Thu, Jun 12, 2008 at 11:46:34AM -0500, Brandon Casey wrote:\n>\n>>\n>> from reflogs even though stashes are implemented using reflogs. The \n>> big\n>> difference is that reflogs are created automatically and stashes \n>> are created\n>> by explicit user action. Automatically deleting something that git \n>> creates\n>> automatically is ok and desirable, doing so for something the user \n>> explicitly\n>> created is not necessarily so.\n>\n> Wincent made this same argument. I don't really agree with it. It is\n> predicated on the assumption that stashing something _is_ asking for \n> git\n> to remember it.\n\nFor me it is quite clear that stashing something _is_ asking for Git \nto remember it. It's an explicit user action. It's a request to \nremember something. Whether or not this is actually the best tool for \nthe job of long-term storage is much less important than the fact that \nthe user explicitly requested it. IMO this trumps all other factors. \nJust because \"stash\" sounds quicker than \"commit\" doesn't make it any \nless of an instruction to Git to store something.\n\nWincent\n"},{"id":"79690","messageId":"0F87000C-B51E-45B8-A21D-1DA184BD603F@wincent.com","threadId":"13904","inReplyTo":"alpine.DEB.1.00.0806130551200.6439@racer","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-13T08:43:59Z","receivedAt":"2008-06-13T08:43:59Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 13/6/2008, a las 6:52, Johannes Schindelin escribió:\n\n> Hi,\n>\n> On Thu, 12 Jun 2008, Eric Raible wrote:\n>\n>> On Thu, Jun 12, 2008 at 1:51 PM, Junio C Hamano \n>> wrote:\n>>> Perhaps\n>>>\n>>> http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670\n>>>\n>>> The user explicitly asks to stash it for a while, where the \n>>> definition of\n>>> the \"while\" comes from reflog's retention period.\n>>\n>> But that doesn't answer the basic question as to why it's ok\n>> to trash data that the user explicitly asked git to save?\n>\n> If the user really asked git to save the changes, she would have\n> _committed_ them.\n>\n> \"git stash\" really is only about shelving quickly and dirtily \n> something\n> you'll need (or maybe need) in a moment.\n>\n> If you need something from the stash a day after stashing it, you \n> have a\n> serious problem with understanding what branches are for.\n\nWhile this may be true for codebases which move forward quickly, what \nabout one which is basically finished and tends not to get touched in \na long time. A situation arises, you stash something, the phone rings, \nand for whatever reason the stash gets forgotten and you don't revisit \nthe project at all for days, weeks, months. It wouldn't be nice to \neventually come back and discover that your in-progress work had been \n\"garbage\" collected for you.\n\nWincent\n"},{"id":"79691","messageId":"m3iqwdra6h.fsf@localhost.localdomain","threadId":"13904","inReplyTo":"20080613074257.GA513@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-13T08:51:28Z","receivedAt":"2008-06-13T08:51:28Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King writes:\n\n> So of course my first question is \"then why didn't you use a branch?\" :)\n> \n> I'm not, by the way, trying to say \"there is no good reason not to use a\n> branch.\" I am trying to figure out what the reasons are, because I\n> wonder if there is a more useful abstraction we can come up for handling\n> this situation.\n> \n> Reading your (and others') responses, it seems like there are two\n> things:\n> \n> 1. Stashing is about saying \"save everything about where I am now with\n> no hassle\". IOW, it's one command, you don't have to decide what\n> goes and what stays, and you can pull it back out with one command.\n> And maybe there is a psychological component that you are not ready\n> to \"commit\" such a work-in-progress (I am extrapolating here, but I\n> know that when I first started with git, I was hesitant to commit\n> because of my experience with other systems).\n[...]\n\nThere is one thing that is easy to do with a stash (due to the way it\nis implemented, even if it complicates it a bit), and you CANNOT do\n(without much hassle) with branches, namely saving state where _index_\nstate matters, either partial commit (or just added files), or\nconflict resolve in progress.\n\nI'm not sure how useful such a thing can be after a month, but if\nproject has slow rate of development (and developer can deal with such\n\"ahlfway\" state decently when restored), it can happen...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"79692","messageId":"bd6139dc0806130153u75c53b4do8e7b63f4a7f144e7@mail.gmail.com","threadId":"13904","inReplyTo":"CA1D4ABE-0B83-44CC-B582-1E85784330AB@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-06-13T08:53:17Z","receivedAt":"2008-06-13T08:53:17Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Fri, Jun 13, 2008 at 10:41 AM, Wincent Colaiuta wrote:\n> El 13/6/2008, a las 7:48, Jeff King escribió:\n>> On Thu, Jun 12, 2008 at 11:46:34AM -0500, Brandon Casey wrote:\n>>> from reflogs even though stashes are implemented using reflogs.\n>>> The big difference is that reflogs are created automatically and\n>>> stashes are created by explicit user action. Automatically deleting\n>>> something that git creates automatically is ok and desirable, doing\n>>> so for something the user explicitly created is not necessarily so.\n>>\n>> Wincent made this same argument. I don't really agree with it. It is\n>> predicated on the assumption that stashing something _is_ asking\n>> for git to remember it.\n\nAn assumption I agree with:\nUse git-stash when you want to record the current state of the working\ndirectory and the index, but want to go back to a clean working\ndirectory. The command saves your local modifications away and reverts\nthe working directory to match the HEAD commit.\n\nNote the \"saves your local modifications\", which is, to me, the same\nas \"please do remember this until I tell you to forget it\".\n\n> For me it is quite clear that stashing something _is_ asking for Git to\n> remember it. It's an explicit user action. It's a request to remember\n> something. Whether or not this is actually the best tool for the job of\n> long-term storage is much less important than the fact that the user\n> explicitly requested it. IMO this trumps all other factors. Just because\n> \"stash\" sounds quicker than \"commit\" doesn't make it any less of an\n> instruction to Git to store something.\n\nI agree fully with what Wincent is saying, stashes have an explicit\nway of cleaning them up:\n Remove all the stashed states. Note that those states will then be\nsubject to pruning, and may be difficult or impossible to recover.\nTo me this suggests that otherwise stashes will _not_ be subject to\npruning, which is exactly what this patch does, it makes sure that\nstashes are not subject to pruning unless you 'git stash clear' first.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"79693","messageId":"bd6139dc0806130156o747fc128hbe28440ed4d228d4@mail.gmail.com","threadId":"13904","inReplyTo":"20080613074257.GA513@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-06-13T08:56:56Z","receivedAt":"2008-06-13T08:56:56Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Fri, Jun 13, 2008 at 9:42 AM, Jeff King wrote:\n> On Fri, Jun 13, 2008 at 09:16:42AM +0200, Andreas Ericsson wrote:\n>> To me, long-living stashes are useful because I can all of a sudden be\n>> pulled away from something I'm working on and set to work on something\n>> entirely different for up to 6 months (so far we haven't had a single\n>> emergency project run longer than that). It doesn't happen a lot, but\n>> it *does* happen.\n>\n> So of course my first question is \"then why didn't you use a branch?\" :)\n\nBecause nobody / not everybody has perfect foresight, sometimes you\ndon't know in advance that what you thought was going to be a\ntemporary stash will turn into a long lived stash. What you are saying\nis that really you should always create a branch, just in case your\ntemporary stash proved to be more long-lived than thought?\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"79694","messageId":"20080613090437.GA4474@sigill.intra.peff.net","threadId":"13904","inReplyTo":"CA1D4ABE-0B83-44CC-B582-1E85784330AB@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-13T09:04:37Z","receivedAt":"2008-06-13T09:04:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 13, 2008 at 10:41:42AM +0200, Wincent Colaiuta wrote:\n\n> For me it is quite clear that stashing something _is_ asking for Git to \n> remember it. It's an explicit user action. It's a request to remember \n> something. Whether or not this is actually the best tool for the job of \n> long-term storage is much less important than the fact that the user \n> explicitly requested it. IMO this trumps all other factors. Just because \n> \"stash\" sounds quicker than \"commit\" doesn't make it any less of an \n> instruction to Git to store something.\n\nI think you missed the point of my email. I understand that it is clear\nto you that you are asking for permanent storage. However, it is equally\nclear to me (and to people involved in the design of git stash) that you\nare not asking for permanent storage, because that is not what git stash\ndoes.\n\nIn other words, we are both proceeding from impressions of what the tool\nis meant to do, and what we are asking it to do.\n\nIf you are making the argument that new users will be confused, that the\ndocumentation is insufficient, or that this is inconsistent with other\naspects of git's interface, then those are good reasons to argue what\nstash _should_ do.\n\nThat being said, see the exchanges between Andreas and myself elsewhere\nin the thread. I think there is a reasonable argument that \"git stash\"\n_is_ useful for long term storage, and that one way we can support that\nis removing the expiration.\n\nSo while I prefer the expiration behavior, I think it is reasonable to\nsacrifice that to help adapt the tool for a different workflow.\n\n-Peff\n"},{"id":"79695","messageId":"20080613090739.GA8265@mithlond.arda.local","threadId":"13904","inReplyTo":"bd6139dc0806130153u75c53b4do8e7b63f4a7f144e7@mail.gmail.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-06-13T09:07:39Z","receivedAt":"2008-06-13T09:07:39Z","isPatch":true,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Sverre Rabbelier wrote (2008-06-13 10:53 +0200):\n\n> On Fri, Jun 13, 2008 at 10:41 AM, Wincent Colaiuta \n> wrote:\n> \n> > For me it is quite clear that stashing something _is_ asking for Git\n> > to remember it. It's an explicit user action. It's a request to\n> > remember something. Whether or not this is actually the best tool\n> > for the job of long-term storage is much less important than the\n> > fact that the user explicitly requested it.\n[...]\n> I agree fully with what Wincent is saying, stashes have an explicit\n> way of cleaning them up:\n\nI agree too. I didn't even know that stashes are currently expired\nautomatically. I don't use them that much but I'd expect that what\nI explicitly ask to save stays there until I decide otherwise.\n"},{"id":"79696","messageId":"20080613091040.GB4474@sigill.intra.peff.net","threadId":"13904","inReplyTo":"bd6139dc0806130156o747fc128hbe28440ed4d228d4@mail.gmail.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-13T09:10:40Z","receivedAt":"2008-06-13T09:10:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 13, 2008 at 10:56:56AM +0200, Sverre Rabbelier wrote:\n\n> > So of course my first question is \"then why didn't you use a branch?\" :)\n> \n> Because nobody / not everybody has perfect foresight, sometimes you\n> don't know in advance that what you thought was going to be a\n> temporary stash will turn into a long lived stash. What you are saying\n> is that really you should always create a branch, just in case your\n> temporary stash proved to be more long-lived than thought?\n\nWell, two things here:\n\n 1. I was being somewhat tounge in cheek with that comment. If you read\n the rest of the email, I was trying to figure out reasons why\n people are using \"git stash\" for long-term storage, to see if we\n could improve the branch interface or find a middle ground between\n temporary stashes and branches.\n\n 2. You don't need perfect foresight. Sometime in the thirty days (but\n probably about 5 minutes later) you realize \"oh, this is some\n stashed work that I'm not going to deal with for a while\" and you\n promote it to a topic branch.\n\n But then, I have good reason to want works-in-progress to become\n topic branches: I can then push them to a location which is backed\n up, and from which I can retrieve them if I want to access them\n from a different machine. Not everybody uses the same workflow.\n If you don't see any other benefits to topic branches, then the\n promotion is just a pain.\n\n-Peff\n"},{"id":"79697","messageId":"20080613091304.GC4474@sigill.intra.peff.net","threadId":"13904","inReplyTo":"0F87000C-B51E-45B8-A21D-1DA184BD603F@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-13T09:13:04Z","receivedAt":"2008-06-13T09:13:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 13, 2008 at 10:43:59AM +0200, Wincent Colaiuta wrote:\n\n> While this may be true for codebases which move forward quickly, what \n> about one which is basically finished and tends not to get touched in a \n> long time. A situation arises, you stash something, the phone rings, and \n> for whatever reason the stash gets forgotten and you don't revisit the \n> project at all for days, weeks, months. It wouldn't be nice to eventually \n> come back and discover that your in-progress work had been \"garbage\" \n> collected for you.\n\nI think this argues more for increasing the expiration period on\nreflogs, if your project moves very slowly.\n\n-Peff\n"},{"id":"79698","messageId":"7vtzfxwtt0.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"20080613074257.GA513@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-13T09:47:07Z","receivedAt":"2008-06-13T09:47:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Reading your (and others') responses, it seems like there are two\n> things:\n>\n> 1. Stashing is about saying \"save everything about where I am now with\n> no hassle\". IOW, it's one command, you don't have to decide what\n> goes and what stays, and you can pull it back out with one command.\n> And maybe there is a psychological component that you are not ready\n> to \"commit\" such a work-in-progress (I am extrapolating here, but I\n> know that when I first started with git, I was hesitant to commit\n> because of my experience with other systems).\n>\n> 2. Branches tend to get shared, and you don't want people to see your\n> stashes, because they are messy works in progress.\n>\n> To deal with '2', I wonder if it would be worth making some branches\n> inaccessible to pushing/pulling (either via config, or through a special\n> naming convention).\n\nI personally do not find the example that Andreas gave unconvincing, not\nbecause I doubt it happens in practice, but because I think it shows a bad\ninter-developer communication.\n\nIt is natural to have branches that are private and/or not meant to be\nbuilt on top of by others. We all have them --- heck, I have one that is\ncalled 'pu' (not private but it is meant to be \"only look, never touch\"\nand advertised as such). But if we need a strong mechanism to enforce\nthat \"never touch\" policy by not allowing fetch, there is something wrong\nwith the inter-developer communication.\n\nWhile digging the original thread earlier today (eh, it is already\nyesterday here), I was thinking about what other alternative design and\nimplementation would have been sensible. Here are some thoughts.\n\n * We _did not have to_ make stashes into refs/stash@{$N}. We could have\n implemented them as individual refs under \"refs/stash/$N\" hierarchy.\n E.g. refs/stashes/1, refs/stash/2, etc.\n\n As a side note, we also could have implemented per-branch stash as\n refs/stashes/master@{$N} or refs/stashes/$branch/$N (and we still can.\n Perhaps we can have \"git stash save -B\" option that tells the command\n to send the resulting stash to the per-branch namespace).\n\n * We however chose to take advantage of the auto reclamation behaviour of\n reflog, and for most practical purposes, it is a good thing.\n\n * We later introduced \"drop\" because even as a volatile and short-lived\n collection of local modifications, you can tell that some stashes are\n utter crap immediately while deciding that some are worth keeping, even\n for a short term.\n\n This mechanism was however meant for uncluttering the set of stashes.\n \"drop\" names what you want to discard right now, and by doing so,\n implicitly names what you want to keep for a bit longer (by not naming\n them). It's a reverse operation -- to make your gems easier to find,\n you discard garbage stash entries. It is a useful work element.\n\n * We could add \"keep\" which is a complementary operation to \"drop\". This\n would mark a stash as a gem in a more direct way, excempt even from the\n usual auto pruning.\n\n We probably implement this by marking the entry with a magic timestamp\n value, and teach reflog expiry machinery to keep it indefinitely. You\n can still explicitly \"drop\" it.\n\nI do not want to conflate two possibly independent issues, but I wonder if\nthere is a correlation between a change that people would want to stash to\na per-branch stash (if such a thing existed) and a change the people would\nwant to \"keep\" (if such a feature existed).\n\nIf there is a strong correlation between the two, one possible solution\nwould be to introduce refs/stashes/$branch/ namespace that holds each\nstash as an individual, numbered ref under it. They will live forever\nuntil the user explicitly asks for their removal. If we go this route, we\nwould need a few niceties such as a way to move a \"quick stash\" that is\nrepresented as a reflog entry into a \"longlived stash\" that is represented\nas an individual ref under refs/stashes/$branch/.\n\nBut let's not talk nor think about per-branch stash for now. How does the\n\"keep\" thing sound to people?\n"},{"id":"79701","messageId":"m3ej71r6ob.fsf@localhost.localdomain","threadId":"13904","inReplyTo":"7vtzfxwtt0.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-13T10:05:47Z","receivedAt":"2008-06-13T10:05:47Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano writes:\n\n> * We however chose to take advantage of the auto reclamation behaviour of\n> reflog, and for most practical purposes, it is a good thing.\n\nBy the way, this makes stashes a bit similar to using $TMPDIR to store\nfiles with 'tmpwatch' (or equivalent) enabled. Is this a good analogy?\n\n[...]\n> But let's not talk nor think about per-branch stash for now. How does the\n> \"keep\" thing sound to people?\n\nThis looks nice, although I'd rather not use any magic. I'm only\nafraid that people would notice that some stash / stash entry should\nhave been \"kept\" when it is too late.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"79705","messageId":"bd6139dc0806130333n2cfbc564k79ed5562f14fc848@mail.gmail.com","threadId":"13904","inReplyTo":"7vtzfxwtt0.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-06-13T10:33:41Z","receivedAt":"2008-06-13T10:33:41Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Fri, Jun 13, 2008 at 11:47 AM, Junio C Hamano wrote:\n\n\n\n> But let's not talk nor think about per-branch stash for now. How does the\n> \"keep\" thing sound to people?\n\nI'm divided on this:\n OOH: I like the idea of having a keep command to mark stashes as\nvaluable, making them not expire until dropped explicitly. Such a\nfeature would also encourage user to go through their stashes every\nnow and then and decide which ones are valuable, and which ones were\nindeed not that valuable and may be dropped.\n\n OTOH: I dislike the idea of 'forcing' the users to go through their\nstashes lest they lose their work. I don't see why anybody would want\nto do some work, stash it, and then \"for no apparent reason\" (the\nreason being not touching it for some time) lose it later. What if\ntheir system borks up and gives a wrong value as current time (say, 10\nyears in the future), all of a sudden their stashes are gone, and they\nmight not even find out till it was too late. Sure, they'd lose some\nstale objects too, but that I can live with, those they did not ask\ngit to take care of explicitly!\n\nThe per-branch stashes sounds very nice, especially if you can get a\n'git stash list --all' feature, that shows all stashes, regardless of\nwhat branch they are on. I myself would use such a per-branch feature\nmost of the time, it would be nice to have a config option that\ndefaults to that (making 'git stash' create a per-branch stash by\ndefault that is).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"79706","messageId":"buoabhptwma.fsf@dhapc248.dev.necel.com","threadId":"13904","inReplyTo":"20080613091040.GB4474@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-06-13T11:14:37Z","receivedAt":"2008-06-13T11:14:37Z","isPatch":true,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Jeff King writes:\n> 2. You don't need perfect foresight. Sometime in the thirty days (but\n> probably about 5 minutes later) you realize \"oh, this is some\n> stashed work that I'm not going to deal with for a while\" and you\n> promote it to a topic branch.\n\nThat's exactly the sort of thing that people end up forgetting to do,\neven if they know they know about and understand the issue -- and of\ncourse many (most?) people will be using stashes _without_ knowing about\nthis issue. I suspect both types will be pretty annoyed when they\nrealize their work disappeared...\n\n-Miles\n\n-- \n`To alcohol! The cause of, and solution to,\n all of life's problems' --Homer J. Simpson\n"},{"id":"79707","messageId":"buo4p7xtw9k.fsf@dhapc248.dev.necel.com","threadId":"13904","inReplyTo":"20080613054840.GA27122@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-06-13T11:22:15Z","receivedAt":"2008-06-13T11:22:15Z","isPatch":true,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Jeff King writes:\n> So I think we are disagreeing not on how stashes should expire, but\n> rather on what a stash _is_, and what it is useful for. And I am open to\n> arguments that stashes are useful for longer-term storage. But I also\n> find the expiration behavior useful\n\nI don't think anybody is really arguing that stashes aren't _mostly_\nuseful for short-term storage.\n\nI think the problem is that _sometimes_ stashes end up sticking around\nlonger than people suspect, and this is not necessarily planned (or even\nintentional). I've done it -- I'll stash some changes \"temporarily\" in\na little-used working directory, then end up doing something else and\nforgetting to re-apply the stash. I'll then revisit that working dir a\nlong time later, wonder where my changes are, poke around a bit, and\nfind them in the stash; no prob.\n\n-Miles\n\n-- \n80% of success is just showing up. --Woody Allen\n"},{"id":"79710","messageId":"237967ef0806130505p6082deb5lca15f8f06771b332@mail.gmail.com","threadId":"13904","inReplyTo":"alpine.DEB.1.00.0806130551200.6439@racer","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2008-06-13T12:05:42Z","receivedAt":"2008-06-13T12:05:42Z","isPatch":true,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2008/6/13 Johannes Schindelin :\n> Hi,\n>\n> On Thu, 12 Jun 2008, Eric Raible wrote:\n>\n>> On Thu, Jun 12, 2008 at 1:51 PM, Junio C Hamano wrote:\n>> > Perhaps\n>> >\n>> > http://thread.gmane.org/gmane.comp.version-control.git/84665/focus=84670\n>> >\n>> > The user explicitly asks to stash it for a while, where the definition of\n>> > the \"while\" comes from reflog's retention period.\n>>\n>> But that doesn't answer the basic question as to why it's ok\n>> to trash data that the user explicitly asked git to save?\n>\n> If the user really asked git to save the changes, she would have\n> _committed_ them.\n>\n> \"git stash\" really is only about shelving quickly and dirtily something\n> you'll need (or maybe need) in a moment.\n>\n> If you need something from the stash a day after stashing it, you have a\n> serious problem with understanding what branches are for.\n\nEven if everyone were to eventually agree with this, I think it's a bit rude\nto teach people who stored something important in a stash for a month that\nthis is the case by deleting their work.\n\nEven with the documentation update, if you're a newbie, you might not know\nthat git in some places automatically calls git gc when you git pull, as in\nthe example Brandon gave.\n\n-- \nMikael Magnusson\n"},{"id":"79712","messageId":"19C06D62-966A-4626-A620-2281A7CAA2B6@wincent.com","threadId":"13904","inReplyTo":"7vtzfxwtt0.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-13T12:40:50Z","receivedAt":"2008-06-13T12:40:50Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 13/6/2008, a las 11:47, Junio C Hamano escribió:\n\n> If there is a strong correlation between the two, one possible \n> solution\n> would be to introduce refs/stashes/$branch/ namespace that holds each\n> stash as an individual, numbered ref under it. They will live forever\n> until the user explicitly asks for their removal. If we go this \n> route, we\n> would need a few niceties such as a way to move a \"quick stash\" that \n> is\n> represented as a reflog entry into a \"longlived stash\" that is \n> represented\n> as an individual ref under refs/stashes/$branch/.\n>\n> But let's not talk nor think about per-branch stash for now. How \n> does the\n> \"keep\" thing sound to people?\n\n\nSounds a little bit over-engineered to me.\n\nSo, \"stash\" is intended for short-term storage, but by adding a \"keep\" \noption you're officially blessing it for long-term storage as well. \nAnd the interface that you propose, explicitly marking stuff as \"for \nkeeps\" and being able to move stuff from \"temp\" to \"keep\" sounds quite \ncomplicated.\n\nI honestly think that the simplest solution from both an \nimplementation and a usage perspective is just to keep everything that \nis stashed until the user clears it out. If you use a push/pop model \nthen your stash will never get cluttered up with garbage, and if you \ndo abuse it for long-term storage you'll start to notice that the \nstash list is inconveniently large, thus hinting that perhaps you are \nabusing stash in ways that the designers never intended.\n\nCheers,\nWincent\n"},{"id":"79713","messageId":"20080613131108.GA15876@sigill.intra.peff.net","threadId":"13904","inReplyTo":"19C06D62-966A-4626-A620-2281A7CAA2B6@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-13T13:11:09Z","receivedAt":"2008-06-13T13:11:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 13, 2008 at 02:40:50PM +0200, Wincent Colaiuta wrote:\n\n> Sounds a little bit over-engineered to me.\n>\n> So, \"stash\" is intended for short-term storage, but by adding a \"keep\" \n> option you're officially blessing it for long-term storage as well. And \n> the interface that you propose, explicitly marking stuff as \"for keeps\" \n> and being able to move stuff from \"temp\" to \"keep\" sounds quite \n> complicated.\n\nI agree. I like the expiration of stashes, but if it is a choice between\n\"just don't expire them\" and \"here is a complex set of rules and\nobligations for preventing them from expiring\" I think we are better off\njust leaving them.\n\n-Peff\n"},{"id":"79717","messageId":"48527C13.2000800@freescale.com","threadId":"13904","inReplyTo":"48521EDA.5040802@op5.se","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2008-06-13T13:54:27Z","receivedAt":"2008-06-13T13:54:27Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Andreas Ericsson wrote:\n\n> I think these are the options we're faced with:\n> 1. Never expire stashes (don't shoot the user)\n> 2. Don't treat stashes specially (shoot the user)\n> 3. Don't purge stashes when auto-gc-ing (let the users shoot themselves)\n> 4. Make the behaviour configurable (let the users shoot themselves)\n> 5. Double the expiration time on stashes and warn for them when they should\n> normally have expired (during gc, that is) (shoot the user, but warn \n> first).\n> \n> I'm all for #4 and will cook up a patch for that next week when I'm on\n> vacation unless #1 gets applied before that.\n> \n\nThere are additional choices too, I think, with config-driven\nvariations as well.\n\nAt git-gc time, notice a reflog entry for a stash that\nis about to expire and either convert it to a branch or\ninteractively offer to convert it or delete it.\n\nProvide a command that converts stash entries to branches.\nMaybe even take over refs/stash/ name-space or so?\n\nAll with various config options to do that quietly, interactively,\nalways, never, etc.\n\njdl\n"},{"id":"79739","messageId":"GL75k5fYVorDQQh654Db9qgZ3DAr5EfRqLBwQe-VpacRGGbsy3c7WA@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"20080613054840.GA27122@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-13T16:43:42Z","receivedAt":"2008-06-13T16:43:42Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Jeff King wrote:\n> On Thu, Jun 12, 2008 at 11:46:34AM -0500, Brandon Casey wrote:\n\n>> Also, the sequence above would not have to be performed _exactly_ at the\n>> expiration date. The listing of the stashes i.e. git-log, does not perform\n>> reflog expiration AFAIK. So the initial 'stash list' and the 'git pull' do\n>> not have to straddle the expiration date, they can all be performed any time\n>> after the expiration point to produce the above behavior.\n> \n> No, but it would have to be performed _after_ the expiration, but\n> _before_ any auto-gc happened. So it is a smaller window than \"anytime\n> after expiration\" but not as small as a particular 30-second window.\n\nRight, that's why I showed the 'git-stash list' which still had the stash entry\nbefore the 'git-pull'.\n\n>> from reflogs even though stashes are implemented using reflogs. The big\n>> difference is that reflogs are created automatically and stashes are created\n>> by explicit user action. Automatically deleting something that git creates\n>> automatically is ok and desirable, doing so for something the user explicitly\n>> created is not necessarily so.\n> \n> Wincent made this same argument. I don't really agree with it. It is\n> predicated on the assumption that stashing something _is_ asking for git\n> to remember it. My mental model of stashing is that it hasn't been saved\n> at all, but is rather a convenient way of naming and storing a set of\n> changes for a second while I do something else. I think of it in the\n> same way as a register in vi: I can yank text into it for pasting\n> after a few commands. But I don't expect yanked text to be stored in the\n> register a month later.\n\nFunny you should mentioned that since I had thought of using a similar\nexample in defense of my point of view. So I offer a question: after how\nmuch time after you have yanked some text into a register in vi do you\nexpect vi to clear that register?\n\nI work in a linux environment and as such I use vim. It seems vim retains\ntext yanked to a register even across sessions (terminate vi, start vi, text\nis still yanked). I was not aware of this and I didn't expect it (but it is\na welcome feature). I had expected that registers would be cleared when vi\nwas terminated, but _only_ when vi was terminated. So even if I left a session\nrunning for 2 years, the register with yanked text would not be cleared. And\nthis is not because I think a certain workflow which requires a 2 year vi\nediting session should be encouraged, but just because I told the editor to\ndo something, and I expect it to continue doing it until I tell it to stop.\n\nThere is a difference between git and applications like vi, and that is that\nvi has a 'begin' and an 'end. You begin a vi session, you edit some text, you\nyank, paste, save, then you terminate the session. So it is easy to think of the\nyanks as being tied to the session. Similarly with something like X11 when you\nhighlight text, you expect it to be there in the copy buffer until other text is\nhighlighted or until X terminates.\n\nGit does not really have a 'begin' and an 'end'. Well there is one thing, and\nthat is a clone operation. Transient objects, including stashes are not copied\nto the clone.\n\n> So I think we are disagreeing not on how stashes should expire, but\n> rather on what a stash _is_, and what it is useful for. And I am open to\n> arguments that stashes are useful for longer-term storage. But I also\n> find the expiration behavior useful (I seem to have accumulated some\n> cruft in my stash list, and I expect git to clean it out during a gc,\n> rather than me having to clean it manually). So personally, I would not\n> be in favor of removing the expiration unless I saw evidence that the\n> utility of keeping stashes long-term outweighed the benefit of cleaning.\n> \n> And that evidence is probably \"here is a workflow I find useful, and\n> here is why it is better than any other way of doing it in git\" (and\n> maybe the \"better\" is simply \"new users are going to jump on this way of\n> using stash, even though it was not as intended\").\n\nI see it as less of a workflow issue than a safety issue, and a user interface\nissue. I don't know if there are workflows that would be made possible by\nnot expiring the stash. I do think the benefit of automatically cleaning\nout the stash so it doesn't accumulate old cruft is less important to me\nthan an intuitive interface and predictable behavior.\n\n-brandon\n"},{"id":"79740","messageId":"ZTTd7YVht_gFLPWCKTfGHU9iKdkp9sYEZ4upWUptwV0n-_bvgy23kA@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"20080613055800.GA26768@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-13T16:54:38Z","receivedAt":"2008-06-13T16:54:38Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Jeff King wrote:\n> On Fri, Jun 13, 2008 at 06:26:28AM +0200, Andreas Ericsson wrote:\n\n> Stashes shouldn't expire, because the user told the stash to save\n> information. The user considers it a \"save\" because stashes hold things\n> forever. Stashes hold things forever because they shouldn't expire.\n\nMaybe the command name is the problem. We know that 'git stash' is short\nfor 'git stash save', so we think we are directing git to \"save\" something.\nIn the physical world when I \"save\" something or \"stash\" it away, even\ntemporarilly, I don't stick it in a garbage can and put it out by the curb. :)\n\nSorry, that's just what popped into my head :)\n\n-brandon\n"},{"id":"79743","messageId":"4852A85E.6020406@free.fr","threadId":"13904","inReplyTo":"7vtzfxwtt0.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Olivier Marin","fromEmail":"dkr+ml.git@free.fr","sentAt":"2008-06-13T17:03:26Z","receivedAt":"2008-06-13T17:03:26Z","isPatch":true,"sender":{"key":"dkr+ml.git@free.fr","avatar":null},"body":"Junio C Hamano a écrit :\n> \n> * We _did not have to_ make stashes into refs/stash@{$N}. We could have\n> implemented them as individual refs under \"refs/stash/$N\" hierarchy.\n> E.g. refs/stashes/1, refs/stash/2, etc.\n\nI don't really see what is the need for \"global\" stashes but why not?\n\n> As a side note, we also could have implemented per-branch stash as\n> refs/stashes/master@{$N} or refs/stashes/$branch/$N (and we still can.\n> Perhaps we can have \"git stash save -B\" option that tells the command\n> to send the resulting stash to the per-branch namespace).\n\nI really like your refs/stashes/$branch/$N idea because it seems easier to\nlist and clean with git stash list/drop/clear.\nBut I think stash should stay a per-branch thing by default. What about a\n-g (--global) option instead?\n\n> * We later introduced \"drop\" because even as a volatile and short-lived\n> collection of local modifications, you can tell that some stashes are\n> utter crap immediately while deciding that some are worth keeping, even\n> for a short term.\n\n\"drop\" is nice, but I think the real improvement was \"pop\".\n\n> * We could add \"keep\" which is a complementary operation to \"drop\". This\n> would mark a stash as a gem in a more direct way, excempt even from the\n> usual auto pruning.\n\nI don't like it at all. Why not just have \"keep\" by default? The users can\nalready use \"pop\", \"drop\" and \"clear\" if they want to trash their stash.\n\nOlivier.\n"},{"id":"79746","messageId":"20080613173041.GA7974@sigill.intra.peff.net","threadId":"13904","inReplyTo":"GL75k5fYVorDQQh654Db9qgZ3DAr5EfRqLBwQe-VpacRGGbsy3c7WA@cipher.nrlssc.navy.mil","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-06-13T17:30:42Z","receivedAt":"2008-06-13T17:30:42Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 13, 2008 at 11:43:42AM -0500, Brandon Casey wrote:\n\n> > No, but it would have to be performed _after_ the expiration, but\n> > _before_ any auto-gc happened. So it is a smaller window than \"anytime\n> > after expiration\" but not as small as a particular 30-second window.\n> \n> Right, that's why I showed the 'git-stash list' which still had the\n> stash entry before the 'git-pull'.\n\nRight, but I meant that you would have to perform the example commands\nyou gave after the expiration, but before you had done anything that did\nan auto-gc. So you could do it at day 31, unless on day 30 you had done\na \"git pull\".\n\nBut somebody else mentioned that they leave cloned working trees sitting\naround, and then find them later. So they might truly have done no\ncommands.\n\nAt any rate, I don't think is especially relevant.\n\n> Funny you should mentioned that since I had thought of using a similar\n> example in defense of my point of view. So I offer a question: after how\n> much time after you have yanked some text into a register in vi do you\n> expect vi to clear that register?\n\nAfter 10 other yanks? ;)\n\nI was referring not to the named registers, but to the unnamed ones.\nIOW, I know that vim will keep my registers from session to session. But\nwhen I yank, it implicitly goes into \"0, and the old \"0 bumps to \"1, \"1\nto \"2, and so forth. \"9 is thrown away.\n\nAnd I think that works pretty well in practice. The size is bounded, but\ntext stays around long enough for me to use it. And if I want storage\nthat is guaranteed to last (and I sometimes do), then I use a named\nregister.\n\nNow here we are bounding by time rather than by number of stashes, but\nit is the same concept.\n\n> yanks as being tied to the session. Similarly with something like X11\n> when you highlight text, you expect it to be there in the copy buffer\n> until other text is highlighted or until X terminates.\n\nAh, if only that was how X cut buffers actually worked. ;)\n\n> I see it as less of a workflow issue than a safety issue, and a user\n> interface issue. I don't know if there are workflows that would be\n> made possible by not expiring the stash. I do think the benefit of\n> automatically cleaning out the stash so it doesn't accumulate old\n> cruft is less important to me than an intuitive interface and\n> predictable behavior.\n\nAt this point I am inclined to agree. Enough people seem to want to\nleave things stashed for long periods that it is a potential hazard to\npeople who don't know about the expiration. And while I prefer the\nexpiring cruft behavior, not expiring it isn't _that_ big a deal to me,\ncompared against the potential for loss.\n\n-Peff\n"},{"id":"79745","messageId":"4852AED4.50206@free.fr","threadId":"13904","inReplyTo":"bd6139dc0806130333n2cfbc564k79ed5562f14fc848@mail.gmail.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Olivier Marin","fromEmail":"dkr+ml.git@free.fr","sentAt":"2008-06-13T17:31:00Z","receivedAt":"2008-06-13T17:31:00Z","isPatch":true,"sender":{"key":"dkr+ml.git@free.fr","avatar":null},"body":"Sverre Rabbelier a écrit :\n> \n> OTOH: I dislike the idea of 'forcing' the users to go through their\n> stashes lest they lose their work. I don't see why anybody would want\n> to do some work, stash it, and then \"for no apparent reason\" (the\n> reason being not touching it for some time) lose it later.\n\nI agree. And even without that:\n\n> What if\n> their system borks up and gives a wrong value as current time (say, 10\n> years in the future), all of a sudden their stashes are gone, and they\n> might not even find out till it was too late. Sure, they'd lose some\n> stale objects too, but that I can live with, those they did not ask\n> git to take care of explicitly!\n\nit seems pretty strange to ask the user for a confirmation: are you sure\nyou want to keep what you ask us to store in the stash?\n\n> The per-branch stashes sounds very nice, especially if you can get a\n> 'git stash list --all' feature, that shows all stashes, regardless of\n> what branch they are on. I myself would use such a per-branch feature\n> most of the time, it would be nice to have a config option that\n> defaults to that (making 'git stash' create a per-branch stash by\n> default that is).\n\nI think the same and would prefer per-branch stash by default because I\ndon't see a real use of a \"global\" one but maybe I'm wrong. Perhaps, a\nconfig option could make everyone happy. :-)\n\nOlivier.\n"},{"id":"79774","messageId":"7v3anhuonj.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"bd6139dc0806130333n2cfbc564k79ed5562f14fc848@mail.gmail.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-13T19:21:20Z","receivedAt":"2008-06-13T19:21:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Rabbelier\" writes:\n\n> On Fri, Jun 13, 2008 at 11:47 AM, Junio C Hamano wrote:\n>\n> \n>\n>> But let's not talk nor think about per-branch stash for now. How does the\n>> \"keep\" thing sound to people?\n>\n> I'm divided on this:\n> OOH: I like the idea of having a keep command to mark stashes as\n> valuable, making them not expire until dropped explicitly. Such a\n> feature would also encourage user to go through their stashes every\n> now and then and decide which ones are valuable, and which ones were\n> indeed not that valuable and may be dropped.\n>\n> OTOH: I dislike the idea of 'forcing' the users to go through their\n> stashes lest they lose their work.\n\nThe latter argument is somewhat misguided.\n\nTo stash is like putting something in /tmp on a system that runs a cron\njob to clean out cruft from there once in a while. Another analogy is to\nspitting an information out to syslog, so that it is kept until logs are\nrotated.\n\nIf you want permanent storage, you do not store it in somewhere that is\ndesigned to have automated rotation or pruning. Instead, you would create\na file somewhere in your $HOME or use a branch. It is natural that you do\nnot have perfect foresight --- so after putting something in /tmp, you may\nwish that you can somehow say retroactively that some things you placed\nearlier in /tmp are more valuable than others. \"keep\" was an example of\nhow you _could_ express that wish. In other words, you are not _forced_\nto, but you are merely given an opportunity to do so.\n\nI do not personally care too deeply about the \"keep\" approach. An easier\nto explain (and perhaps easier to implement, too) alternative would be to\nhave a per-ref configuration variable that specifies the reflog retention\nperiod per ref, e.g. \"git config reflog.refs/stash.expire never\".\n\nI however mildly suspect that the stash configured as such would end up to\nbe a lot worse than the current behaviour in practice. It would make\ncrufts easily accumulate in the stash, making it harder to find gems, and\nas a consequence of that, encouraging you to say \"stash clean\" or \"stash\ndrop\" more often, risking accidental removal of what you did not intend\nto (for this exact reason I earlier -- much earlier than the current\nthread -- even thought about suggesting to make the reflog expiry period\nmuch shorter than the usual ref).\n\nBut at that point it is user shooting his foot off ;-)\n"},{"id":"79776","messageId":"5F01034D-8964-47AC-8FB5-F68C44D7FFD5@wincent.com","threadId":"13904","inReplyTo":"7v3anhuonj.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-13T19:35:47Z","receivedAt":"2008-06-13T19:35:47Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 13/6/2008, a las 21:21, Junio C Hamano escribió:\n\n> To stash is like putting something in /tmp on a system that runs a \n> cron\n> job to clean out cruft from there once in a while. Another analogy \n> is to\n> spitting an information out to syslog, so that it is kept until logs \n> are\n> rotated.\n\n\nJudging from the number of people who have chimed in on this thread \nsaying \"I expect Git to remember what I told it to remember\" indicates \nthat all too few think of the stash as being like \"/tmp\" or a logfile. \nThere are two problems:\n\n1) the name of the command, \"stash\" (and worse still \"stash _save_\") \nis giving people a misleading impression about what it does\n\n2) the documentation isn't clear enough about what the command does, \nor people don't read it\n\nI suspect that no matter how good the documentation is, a command \ncalled \"git stash save\" that remembers stuff only temporarily will \ncontinue to evoke reactions of puzzlement for as long as it works that \nway. Seeing as Git is usually extremely conservative about throwing \naway people's stuff, the ephemeralness of \"git stash\" backing store is \nlikely to be quite surprising for many.\n\nWhat are the options?\n\n- improve the documentation\n\n- rename the command (can't see that happening)\n\n- change the behaviour to \"keep\" until popped/cleared\n\nI think the latter's the best, and a patch for it was already posted \nat the beginning of this thread.\n\nCheers,\nWincent\n"},{"id":"79777","messageId":"BirCl2sajPcjvVRXCRm_49PfnXalJDF2v7s7osz-X1yeRkkYOCL6ZQ@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"7v3anhuonj.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-13T19:42:22Z","receivedAt":"2008-06-13T19:42:22Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Junio C Hamano wrote:\n\n> To stash is like putting something in /tmp on a system that runs a cron\n> job to clean out cruft from there once in a while. Another analogy is to\n> spitting an information out to syslog, so that it is kept until logs are\n> rotated.\n\nI like my analogy better. :)\n\ndiff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt\nindex baa4f55..119117e 100644\n--- a/Documentation/git-stash.txt\n+++ b/Documentation/git-stash.txt\n@@ -17,7 +17,11 @@ DESCRIPTION\n Use 'git-stash' when you want to record the current state of the\n working directory and the index, but want to go back to a clean\n working directory. The command saves your local modifications away\n-and reverts the working directory to match the `HEAD` commit.\n+and reverts the working directory to match the `HEAD` commit. You should\n+think of the stash like a garbage can in which you place your temporary\n+work and then bring out to the curb. If you are quick to use your stashed\n+changes you can get them before garbage collection occurs (it's every\n+Tuesday where I live, but git does it every 30 days).\n \n The modifications stashed away by this command can be listed with\n `git-stash list`, inspected with `git-stash show`, and restored\n"},{"id":"79778","messageId":"4852CF51.10902@free.fr","threadId":"13904","inReplyTo":"7v3anhuonj.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Olivier Marin","fromEmail":"dkr+ml.git@free.fr","sentAt":"2008-06-13T19:49:37Z","receivedAt":"2008-06-13T19:49:37Z","isPatch":true,"sender":{"key":"dkr+ml.git@free.fr","avatar":null},"body":"Junio C Hamano a écrit :\n> \n> To stash is like putting something in /tmp on a system that runs a cron\n> job to clean out cruft from there once in a while. Another analogy is to\n> spitting an information out to syslog, so that it is kept until logs are\n> rotated.\n\nAre you sure about the \"temporary\" thing? I'm not a native speaker but all\nthe dictionary I tried, define stash as:\n\n \"to put or hide away (money, valuables, etc.) in a secret or safe place,\n as for future use.\"\n\nAre they all wrong?\n\n> I however mildly suspect that the stash configured as such would end up to\n> be a lot worse than the current behaviour in practice. It would make\n> crufts easily accumulate in the stash, making it harder to find gems, [...]\n\nWhy not encouraging the usage of \"pop\" then?\n\nOlivier.\n"},{"id":"79785","messageId":"alpine.DEB.1.00.0806132239490.6439@racer","threadId":"13904","inReplyTo":"0F87000C-B51E-45B8-A21D-1DA184BD603F@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-13T21:41:40Z","receivedAt":"2008-06-13T21:41:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 13 Jun 2008, Wincent Colaiuta wrote:\n\n> El 13/6/2008, a las 6:52, Johannes Schindelin escribió:\n> \n> >If you need something from the stash a day after stashing it, you have \n> >a serious problem with understanding what branches are for.\n> \n> While this may be true for codebases which move forward quickly, what \n> about one which is basically finished and tends not to get touched in a \n> long time. A situation arises, you stash something, the phone rings, and \n> for whatever reason the stash gets forgotten and you don't revisit the \n> project at all for days, weeks, months. It wouldn't be nice to \n> eventually come back and discover that your in-progress work had been \n> \"garbage\" collected for you.\n\nYou cannot be serious about not wanting to lose the changes when you keep \nthem in _one_ _single_ repository anyway.\n\nAnd you cannot be serious about not wanting to lose the changes when you \nforget about them, for months, even.\n\nSo you are making my point for me.\n\nThanks,\nDscho\n"},{"id":"79795","messageId":"485303AF.2080207@jaeger.mine.nu","threadId":"13904","inReplyTo":"alpine.DEB.1.00.0806132239490.6439@racer","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Christian Jaeger","fromEmail":"christian@jaeger.mine.nu","sentAt":"2008-06-13T23:33:03Z","receivedAt":"2008-06-13T23:33:03Z","isPatch":true,"sender":{"key":"christian@jaeger.mine.nu","avatar":null},"body":"Johannes Schindelin wrote:\n> You cannot be serious about not wanting to lose the changes when you keep \n> them in _one_ _single_ repository anyway.\n>\n> And you cannot be serious about not wanting to lose the changes when you \n> forget about them, for months, even.\n>\n> So you are making my point for me.\n> \n\nMaybe I should describe my way of using Git?:\n\n- I'm (amongst other things) using Git for keeping my own codebase for \nserver maintenance scripts etc, which I then casually replicate between \nmy servers through Git's networking and merging mechanisms. When I need \na new feature, I'm coding it on the particular server where I need it \nand commit it there (I'm even using separate email adresses on every \nserver so that I can track back on which server I wrote a particular \nfeature).\n\n- every now and then, I'm being interrupted when I'm coding something \n(and will not be able to continue on it for days, weeks or months); when \nI return to the repo for something completely different, there's an \nuncommitted file or two or more (all of which might not even work), and \nbefore there was git-stash I would sometimes just let those stay around \nuncommitted in the working tree; this was a bit of a hassle since I \ncould for example not use \"git commit -a\", would IIRC have problems \nmerging changes coming from another repo into those files, and once more \nthan one case of unfinished work accumulated, I could no longer tell \nwhat belonged together; I didn't want it to commit to branches because \nthat didn't seem like a good fit to me (more on that below). Then when \ngit-stash came around, I first thought, \"what's *that*, Git has branches \nalready?\", but then I realized that it would be a perfect fit for \nhandling those unfinished uncommitted things.\n So note that my use case is putting away work which was not finished \n(and usually by accident, i.e. I didn't have the time to choose a \nsensible interruption point and think of a commit message--I'll actually \nusually run \"git stash save\" not upon interruption, but later when I \nwant to do other operations in the same repo), to hopefully be picked up \nagain some (maybe long) time later. (I guess the use case it was \ndesigned for was putting temporarily away intermediate stages of \nconflicting merges and such stuff, i.e. for working as maintainer and \nnot coder?)\n\n- I do backups of the servers. So I don't expect loosing my work even if \nit's only being stored on one server.\n\n- But I was not aware of the expiry policy (missing clarity in the man \npage). So I think I may actually *have* lost some such work already. \nProbably not a big deal, but a bit of a nuisance nonetheless (I wouldn't \ncontinue using git-stash(*)).\n\nYou said in a previous mail \"If you need something from the stash a day \nafter stashing it, you have a\nserious problem with understanding what branches are for.\" I've now \nspent a bit of thinking about how to use branches easily for that; \nshould git stash keep the expiry behaviour, I'll need an easy way of \ndealing with those uncommitted things; basically git stash onto a \nbranch. Since I want it to use a default commit message, and when \napplying it I want the WIP commit undone, I basically want all of the \nsame functionality but using a branch as storage instead. Now, what \nwould be the name of the branch? (Is this calling for discussion of \nhierarchical branch namespaces?). It would need to be such that it \nwouldn't accidentally interfere with WIP branches on other servers--it's \ntwo different works in progress, so using the same branch name would be \nwrong, unless the source prefix (\"origin/\" etc.) separates names well \nenough to not lead to accidents (I don't have enough experience in this \narea; when I'm on branch foo, would \"git pull\" merge another server's \nfoo branch into the current wip branch? etc.).\n\n((*)BTW regarding the comment from Jeff King about the comparison with \nvim's yank buffer and \"bounding by time rather than by number of \nstashes\": yes, why not bound the number of stashes instead? That would \nalso work like history in bash or other tools which limit it by number \nof entries. But I guess the \"preference for forgetting\" is different for \neveryone. Anyway, in my above use case I'm not sure I want the machine \nmake things forgotten for me; would it reduce my work by just not \nreminding me of undone work? Should I let HAL (a fictional intelligent \ncomputer) decide that I've got too much to do and he should decide I \nshould forget about a few things every now and then? I don't have data \nat hand whether that would work and be beneficial for me; it tends to \nupset me when I cannot find info again I know has been somewhere--HAL \ncan't really tell what *I* will forget, after all; I'll just feel like a \nlooser when it happens. Would another analogy be: shouldn't Git drop \nhistory entries after, say, three years, since nobody should care about \nold stuff anymore by then?)\n\nMaybe, if the list of stashes really grows unbounded for some people, \nthere should be a tool to display stashes in the tree, instead of only \nlisting them in linear form? i.e. gitk would show the stashes kind of \nlike branches; of course there's also a linear list of branches--so \nmaybe stashes *should* be branches but in a different namespace (a \nsub-local namespace), hence my thought above about hierarchical \nnamespaces. To sum it all up: using branches makes sense to me, but the \nfeatures that \"git stash\" offers (separated 'namespace' from normal \nbranches, and the automatic \"git reset HEAD^\" for removing the WIP \ncommit) are missing there yet.\n\nChristian.\n"},{"id":"79799","messageId":"200806140117.m5E1HZj6032168@mi0.bluebottle.com","threadId":"13904","inReplyTo":"7v3anhuonj.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2008-06-14T01:16:42Z","receivedAt":"2008-06-14T01:16:42Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano :\n\n> I do not personally care too deeply about the \"keep\" approach. An easier\n> to explain (and perhaps easier to implement, too) alternative would be to\n> have a per-ref configuration variable that specifies the reflog retention\n> period per ref, e.g. \"git config reflog.refs/stash.expire never\".\n\nI think I am primarily responsible for this auto expiration\nbehavior of git-stash command. The original use case that led\nto my git-save script was only about very short-term use. To\ntell you the truth, I did not even realize myself that I can use\nstash@{<>} to refer to more than one states until\nJohannes Schindelin pointed it out to me. It was only about\nsaving the current state once, and that proves it was about very\nshort-term use and nothing else.\n\nBut I think git-stash may have outgrown the original motivation.\n\nConfigurable expiration period per reflog like you suggested\nsounds like the most sane solution to the issue to me. I think\nthat approach is especially attractive because it can kill a few\nbirds with the same stone. You can configure remote tracking\nbranches' logs to expire much sooner than your own branches'\nones, for example.\n\nBut I think \"reflog.refs/stash.expire\" you mentioned above is a\nbad name. Because the default expiration period is configured\nwith \"gc.reflogexpire\", it would be better to make the variable\nname start with \"gc\".\n\nBy the way, I sent a documentation patch to git-stash but did\nnot hear any response. Was there anything wrong with it?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nFind out how you can get spam free email.\nhttp://www.bluebottle.com/tag/3\n"},{"id":"79832","messageId":"612BAE20-8DF3-4323-8AEF-527B92122A7A@wincent.com","threadId":"13904","inReplyTo":"alpine.DEB.1.00.0806132239490.6439@racer","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-06-14T08:58:58Z","receivedAt":"2008-06-14T08:58:58Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 13/6/2008, a las 23:41, Johannes Schindelin escribió:\n\n> Hi,\n>\n> On Fri, 13 Jun 2008, Wincent Colaiuta wrote:\n>\n>> El 13/6/2008, a las 6:52, Johannes Schindelin escribió:\n>>\n>>> If you need something from the stash a day after stashing it, you \n>>> have\n>>> a serious problem with understanding what branches are for.\n>>\n>> While this may be true for codebases which move forward quickly, what\n>> about one which is basically finished and tends not to get touched \n>> in a\n>> long time. A situation arises, you stash something, the phone \n>> rings, and\n>> for whatever reason the stash gets forgotten and you don't revisit \n>> the\n>> project at all for days, weeks, months. It wouldn't be nice to\n>> eventually come back and discover that your in-progress work had been\n>> \"garbage\" collected for you.\n>\n> You cannot be serious about not wanting to lose the changes when you \n> keep\n> them in _one_ _single_ repository anyway.\n>\n> And you cannot be serious about not wanting to lose the changes when \n> you\n> forget about them, for months, even.\n>\n> So you are making my point for me.\n\nYour arguments are _totally_ spurious.\n\nWith respect to your first point, I didn't even mention repository \nduplication and backups so I don't know why you tried to inject it \ninto the discussion. I am _completely_ serious about preserving my \ndata in the repos I work on, and that's why I do automated backups of \nthe home directory which contains all of my local working repos every \ntwo hours (ie 12 times per day), plus an automated whole-disk backup \nonce every 24 hours. However, my point about \"git stash\" is completely \nindependent of my backup regimen; the backup regimen exists to protect \nme against disk and system failures, not to protect me from my SCM.\n\nAnd on your second point, you are arguing that anything you can't \nremember isn't worth keeping, which just isn't a sustainable argument. \nCan you remember the thousands of commits in Git's complete history? \nWould it be okay to just throw away the changes you've forgotten about?\n\nSo I don't think I've made your point for you at all; it remains for \nyou to make it for yourself. But it seems to me that you are arguing \nagainst the sizeable majority of participants on this thread which has \nalready dragged on too long.\n\nSo, let's recap:\n\n(1) It is reasonable to expect, and in fact it is clear that most \nusers _do_ expect, that Git should indefinitely remember changes that \nthey told it to remember with \"git stash save\"\n\n(2) The people largely responsible for the implementation of \"git \nstash\" never envisaged its use for long term storage (either \nintentional abuse of \"stash\", or inadvertent misuse) and architected \nit in such a way that it can \"forget\" stashes after a period of time\n\nSo far you've only attacked the first point, and your defense of the \nsecond point has consisted of nothing more than an affirmation that \nthe status quo should remain in place because that's the way it's \nalways been. I haven't yet heard any explanation of _why_ it's such a \nbig deal to adjust the behaviour of the tool to match user \nexpectations, expectations created partly by poor documentation but \nmostly by an unfortunate choice of name for the \"stash\" command.\n\nWe have a choice: re-educate users or modify the tool, and re- \neducation seems of questionable value (for what?) and much more \ndifficult than the latter, which has next to no cost at all. Modify \nthe tool and we won't have to re-educate users: those who abuse \"git \nstash\" for long term storage will soon figure out that they're not \nusing it in the best possible way when their stash list gets out of \nhand, and as an added bonus nobody will ever get burnt by Git throwing \naway something that they thought it should have kept.\n\nAn auto-expiration config variable should be enough to keep people \nlike you happy, as you'll get to keep your auto-garbage-collected \nstash list, but the auto-expiration should be _off_ by default because \nit's best to err on the conservative side about throwing out data. \nEspecially in a case like this one where it is clearly demonstrated \nthat most people are surprised to learn that Git garbage collects old \nstashes.\n\nAnyway, I've now stated and restated these arguments enough times and \nI don't think I have anything to add.\n\nWincent\n"},{"id":"79895","messageId":"200806142359.m5ENxsBI028758@mi0.bluebottle.com","threadId":"13904","inReplyTo":"612BAE20-8DF3-4323-8AEF-527B92122A7A@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"しらいしななこ","fromEmail":"nanako3@bluebottle.com","sentAt":"2008-06-14T23:59:38Z","receivedAt":"2008-06-14T23:59:38Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Wincent Colaiuta writes:\n\n> (2) The people largely responsible for the implementation of \"git\n> stash\" never envisaged its use for long term storage (either\n> intentional abuse of \"stash\", or inadvertent misuse) and architected\n> it in such a way that it can \"forget\" stashes after a period of time\n\nI apologize for my lack of perfect foresight as the original\nauthor of the command. As I already said, I think expiration\nperiod of reflogs that is configurable for each ref as suggested\nearlier by Junio makes sense.\n\nBut changing the default expiration \"never\" for stash has its\nown problem and I think we need to modify the way a stash entry\nis created to solve it.\n\nYou will find in the DISCUSSION section of git-stash manual page\nthat a stash entry is represented as a commit that is a merge\nbetween the commit the stash was made on (H), and a fake commit\nwhose tree records the contents of the index (I). The merge\ncommit itself records the state of the files in the working\ndirectory as its tree (W):\n\n .----W\n / /\n -----H----I\n\nIf you do not expire stash forever, you will keep the history\nbehind the commit H. This is unnecessary and is problematic\nparticularly if you rebase your branches frequently.\n\nIn order to apply a stash, all you need is the tree of the three\ncommits contained in this structure. You do not need the\nhistory behind commit H.\n\nThe following is a trial patch to change how a stash is recorded.\nWith this patch I do not think we will keep unnecessary commits\nbehind H in the repository even when a stash is kept forever.\n\ndiff --git a/git-stash.sh b/git-stash.sh\nindex 4938ade..f4c4236 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -54,6 +54,9 @@ create_stash () {\n \tfi\n \tmsg=$(printf '%s: %s' \"$branch\" \"$head\")\n \n+\t# create the base commit that is parentless\n+\tb_commit=$(printf 'base of %s\\n' \"$msg\" | git commit-tree \"HEAD:\")\n+\n \t# state of the index\n \ti_tree=$(git write-tree) &&\n \ti_commit=$(printf 'index on %s\\n' \"$msg\" |\n\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n\n----------------------------------------------------------------------\nGet a free email address with REAL anti-spam protection.\nhttp://www.bluebottle.com/tag/1\n"},{"id":"79900","messageId":"alpine.DEB.1.00.0806150457180.6439@racer","threadId":"13904","inReplyTo":"200806142359.m5ENxsBL028758@mi0.bluebottle.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-15T04:00:46Z","receivedAt":"2008-06-15T04:00:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 15 Jun 2008, しらいしななこ wrote:\n\n> The following is a trial patch to change how a stash is recorded.\n> With this patch I do not think we will keep unnecessary commits\n> behind H in the repository even when a stash is kept forever.\n> \n> diff --git a/git-stash.sh b/git-stash.sh\n> index 4938ade..f4c4236 100755\n> --- a/git-stash.sh\n> +++ b/git-stash.sh\n> @@ -54,6 +54,9 @@ create_stash () {\n> \tfi\n> \tmsg=$(printf '%s: %s' \"$branch\" \"$head\")\n> \n> +\t# create the base commit that is parentless\n> +\tb_commit=$(printf 'base of %s\\n' \"$msg\" | git commit-tree \"HEAD:\")\n> +\n\nI think that this does not help the case of Wincent (which I do not agree \nwith), as it does not prevent the stashes from expiring.\n\nWhat your patch does, however, might be something people need to prevent \nunnecessary bloat of the object database, if they choose never to expire \nstashes.\n\nHowever, it makes it harder to see where the stashed revision came from.\n\nBesides, I think that your printf would look nicer as\n\n\tb_commit=$(echo \"base of $msg\" | git commit-tree HEAD^{tree})\n\nCiao,\nDscho\n"},{"id":"79903","messageId":"7vabhne15k.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"612BAE20-8DF3-4323-8AEF-527B92122A7A@wincent.com","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-15T05:07:51Z","receivedAt":"2008-06-15T05:07:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"しらいしななこ writes:\n\n> I apologize for my lack of perfect foresight as the original\n> author of the command. As I already said, I think expiration\n> period of reflogs that is configurable for each ref as suggested\n> earlier by Junio makes sense.\n\nYou do not need to be overly apologetic.\n\nIt's not your fault that the way you originally scratched your own itch is\nalready 90% useful to others in different context of theirs but with 10%\n\"caveat emptor\". Others owe kudos to you for what they're given, and the\nway for them to thank you would be to scratch their own itch by filling\nthe remaining 10% to make it work better in their context, not by bitching\nand quibbling on what the dictionary definition of the word \"stash\" is.\n\n> But changing the default expiration \"never\" for stash has its\n> own problem and I think we need to modify the way a stash entry\n> is created to solve it.\n> ...\n> If you do not expire stash forever, you will keep the history\n> behind the commit H. This is unnecessary and is problematic\n> particularly if you rebase your branches frequently.\n>\n> In order to apply a stash, all you need is the tree of the three\n> commits contained in this structure. You do not need the\n> history behind commit H.\n>\n> The following is a trial patch to change how a stash is recorded.\n> With this patch I do not think we will keep unnecessary commits\n> behind H in the repository even when a stash is kept forever.\n\nKeeping stashes indefinitely is a relatively easy change (even though\nthere may need design discussions on the cleanest way to do so) but nobody\nso far seemed to have thought about the ramifications of doing so. I am\nglad somebody is thinking one step ahead, and I think what you raised is a\nvalid concern. Crufts from rebases will usually be purged from repository\nthanks to reflog autoexpiration, but if somebody keeps a stash that was\nmade on a commit that has long been rebased away, it will keep the rebased\ncommits pinned to the repository, and we are talking about indefinite\nretention here. People should get worried.\n\nI suspect this won't be a huge issue, but the only reason behind that\nsuspicion is because I expect people won't have insane number of rebases\nnor keep insane number of stash entries, so the extra cruft that is kept\nbehind the stash entries won't be insanely large. But people are known to\nbe insane enough to break my expectations, so I'd say we should make\nthings safer before we make the change to keep stashes forever by default.\n\nI think the steps from here on would be:\n\n - Apply the patch in your message I am responding to, so that a stash\n that is kept forever will not pin the unnecessary history behind it in\n the repository. As you said there is no reason to make the base commit\n (H) actually the same as the commit in the true history --- the only\n thing we care about it is its tree object;\n\n - Design and decide the way to tell git to make stash entries unexpirable\n (or maybe have very long expiration period). I am leaning toward a\n configuration option that lets you specify expiration period per ref,\n rather than marking individual reflog entries as I suggested earlier;\n\n - Make the default for new repositories' stash reflog expiry period\n \"never\", by setting the above configuration upon \"git init\".\n\nNone of the above should obviously be in 1.5.6, but I think even the third\nstep to the change the default would be acceptable in the next 1.6.0\nrelease.\n"},{"id":"80001","messageId":"279b37b20806152033o58350d77v77f859542b4542b3@mail.gmail.com","threadId":"13904","inReplyTo":"7vabhne15k.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2008-06-16T03:33:27Z","receivedAt":"2008-06-16T03:33:27Z","isPatch":true,"sender":{"key":"raible@gmail.com","avatar":null},"body":"2008/6/14 Junio C Hamano :\n> I think the steps from here on would be:\n>\n> - Apply the patch in your message I am responding to, so that a stash\n> that is kept forever will not pin the unnecessary history behind it in\n> the repository. As you said there is no reason to make the base commit\n> (H) actually the same as the commit in the true history --- the only\n> thing we care about it is its tree object;\n>\n> - Design and decide the way to tell git to make stash entries unexpirable\n> (or maybe have very long expiration period). I am leaning toward a\n> configuration option that lets you specify expiration period per ref,\n> rather than marking individual reflog entries as I suggested earlier;\n>\n> - Make the default for new repositories' stash reflog expiry period\n> \"never\", by setting the above configuration upon \"git init\".\n>\n> None of the above should obviously be in 1.5.6, but I think even the third\n> step to the change the default would be acceptable in the next 1.6.0\n> release.\n\nIn addition, how about a new stash option \"expire\", as in:\ngit stash expire --before=2.weeks.ago\n\nThe default for expire should probably be default expiration period;\nif set to \"never\" then a usage message could be printed.\n\nI for one would choose \"never\", so the above would be a simple\nway of cleaning up if/when too much cruft accumulates.\n\n- Eric\n"},{"id":"80005","messageId":"7vy755c0b2.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"7vabhne15k.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-16T07:21:21Z","receivedAt":"2008-06-16T07:21:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I think the steps from here on would be:\n>\n> - Apply the patch in your message I am responding to, so that a stash\n> that is kept forever will not pin the unnecessary history behind it in\n> the repository. As you said there is no reason to make the base commit\n> (H) actually the same as the commit in the true history --- the only\n> thing we care about it is its tree object;\n>\n> - Design and decide the way to tell git to make stash entries unexpirable\n> (or maybe have very long expiration period). I am leaning toward a\n> configuration option that lets you specify expiration period per ref,\n> rather than marking individual reflog entries as I suggested earlier;\n>\n> - Make the default for new repositories' stash reflog expiry period\n> \"never\", by setting the above configuration upon \"git init\".\n>\n> None of the above should obviously be in 1.5.6, but I think even the third\n> step to the change the default would be acceptable in the next 1.6.0\n> release.\n\nSo here is the second step from the above list. I did not write any test\nnor docs, but if people are so keen to see permanent stashes supported, I\nam reasonably sure that they will contribute by filling the gap even if I\ndo not do anything further ;-)\n\nObviously this will _not_ come anywhere near 'master' nor 'next' until\n1.5.6 ships.\n\n-- >8 --\n\nFrom: Junio C Hamano \nDate: Sun, 15 Jun 2008 23:48:46 -0700\nSubject: [PATCH] Per-ref reflog expiry configuration\n\nIn addition to gc.reflogexpireunreachable and gc.reflogexpire, this lets\nyou set gc..reflogexpireunreachable and gc..reflogexpire\nvariables.\n\nWhen \"git reflog expire\" expires reflog entry for $ref, the expiry timers\nare taken from the first that matches $ref (and if there isn't\nthe global default value is used).\n\nFor example, you could:\n\n\t[gc \"refs/stash\"]\n\t\treflogexpire = never\n\t\treflogexpireunreachable = never\n\n\t[gc \"refs/remotes/*\"]\n\t\treflogexpire = 7 days\n\t\treflogexpireunreachable = 3 days\n\n\t[gc]\n\t\treflogexpire = 90 days\n\t\treflogexpireunreachable = 30 days\n\nSigned-off-by: Junio C Hamano \n---\n builtin-reflog.c | 145 +++++++++++++++++++++++++++++++++++++++++++++++-------\n 1 files changed, 126 insertions(+), 19 deletions(-)\n\ndiff --git a/builtin-reflog.c b/builtin-reflog.c\nindex b151e24..eec14c7 100644\n--- a/builtin-reflog.c\n+++ b/builtin-reflog.c\n@@ -269,7 +269,9 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,\n \tint status = 0;\n \n \tmemset(&cb, 0, sizeof(cb));\n-\t/* we take the lock for the ref itself to prevent it from\n+\n+\t/*\n+\t * we take the lock for the ref itself to prevent it from\n \t * getting updated.\n \t */\n \tlock = lock_any_ref_for_update(ref, sha1, 0);\n@@ -331,21 +333,119 @@ static int collect_reflog(const char *ref, const unsigned char *sha1, int unused\n \treturn 0;\n }\n \n-static int reflog_expire_config(const char *var, const char *value, void *cb)\n+static struct reflog_expire_cfg {\n+\tstruct reflog_expire_cfg *next;\n+\tunsigned long expire_total;\n+\tunsigned long expire_unreachable;\n+\tsize_t len;\n+\tchar pattern[FLEX_ARRAY];\n+} *reflog_expire_cfg, **reflog_expire_cfg_tail;\n+\n+static struct reflog_expire_cfg *find_cfg_ent(const char *pattern, size_t len)\n {\n-\tif (!strcmp(var, \"gc.reflogexpire\")) {\n-\t\tif (!value)\n-\t\t\tconfig_error_nonbool(var);\n-\t\tdefault_reflog_expire = approxidate(value);\n+\tstruct reflog_expire_cfg *ent;\n+\n+\tif (!reflog_expire_cfg_tail)\n+\t\treflog_expire_cfg_tail = &reflog_expire_cfg;\n+\n+\tfor (ent = reflog_expire_cfg; ent; ent = ent->next)\n+\t\tif (ent->len == len &&\n+\t\t !memcmp(ent->pattern, pattern, len))\n+\t\t\treturn ent;\n+\n+\tent = xcalloc(1, (sizeof(*ent) + len));\n+\tmemcpy(ent->pattern, pattern, len);\n+\tent->len = len;\n+\t*reflog_expire_cfg_tail = ent;\n+\treflog_expire_cfg_tail = &(ent->next);\n+\treturn ent;\n+}\n+\n+static int parse_expire_cfg_value(const char *var, const char *value, unsigned long *expire)\n+{\n+\tif (!value)\n+\t\treturn config_error_nonbool(var);\n+\tif (!strcmp(value, \"never\") || !strcmp(value, \"false\")) {\n+\t\t*expire = 0;\n \t\treturn 0;\n \t}\n-\tif (!strcmp(var, \"gc.reflogexpireunreachable\")) {\n-\t\tif (!value)\n-\t\t\tconfig_error_nonbool(var);\n-\t\tdefault_reflog_expire_unreachable = approxidate(value);\n+\t*expire = approxidate(value);\n+\treturn 0;\n+}\n+\n+/* expiry timer slot */\n+#define EXPIRE_TOTAL 01\n+#define EXPIRE_UNREACH 02\n+\n+static int reflog_expire_config(const char *var, const char *value, void *cb)\n+{\n+\tconst char *lastdot = strrchr(var, '.');\n+\tunsigned long expire;\n+\tint slot;\n+\tstruct reflog_expire_cfg *ent;\n+\n+\tif (!lastdot || prefixcmp(var, \"gc.\"))\n+\t\treturn git_default_config(var, value, cb);\n+\n+\tif (!strcmp(lastdot, \".reflogexpire\")) {\n+\t\tslot = EXPIRE_TOTAL;\n+\t\tif (parse_expire_cfg_value(var, value, &expire))\n+\t\t\treturn -1;\n+\t} else if (!strcmp(lastdot, \".reflogexpireunreachable\")) {\n+\t\tslot = EXPIRE_UNREACH;\n+\t\tif (parse_expire_cfg_value(var, value, &expire))\n+\t\t\treturn -1;\n+\t} else\n+\t\treturn git_default_config(var, value, cb);\n+\n+\tif (lastdot == var + 2) {\n+\t\tswitch (slot) {\n+\t\tcase EXPIRE_TOTAL:\n+\t\t\tdefault_reflog_expire = expire;\n+\t\t\tbreak;\n+\t\tcase EXPIRE_UNREACH:\n+\t\t\tdefault_reflog_expire_unreachable = expire;\n+\t\t\tbreak;\n+\t\t}\n \t\treturn 0;\n \t}\n-\treturn git_default_config(var, value, cb);\n+\n+\tent = find_cfg_ent(var + 3, lastdot - (var+3));\n+\tif (!ent)\n+\t\treturn -1;\n+\tswitch (slot) {\n+\tcase EXPIRE_TOTAL:\n+\t\tent->expire_total = expire;\n+\t\tbreak;\n+\tcase EXPIRE_UNREACH:\n+\t\tent->expire_unreachable = expire;\n+\t\tbreak;\n+\t}\n+\treturn 0;\n+}\n+\n+static void set_reflog_expiry_param(struct cmd_reflog_expire_cb *cb, int slot, const char *ref)\n+{\n+\tstruct reflog_expire_cfg *ent;\n+\n+\tif (slot == (EXPIRE_TOTAL|EXPIRE_UNREACH))\n+\t\treturn; /* both given explicitly -- nothing to tweak */\n+\n+\tfor (ent = reflog_expire_cfg; ent; ent = ent->next) {\n+\t\tif (!fnmatch(ent->pattern, ref, 0)) {\n+\t\t\tif (!(slot & EXPIRE_TOTAL))\n+\t\t\t\tcb->expire_total = ent->expire_total;\n+\t\t\tif (!(slot & EXPIRE_UNREACH))\n+\t\t\t\tcb->expire_unreachable = ent->expire_unreachable;\n+\t\t\treturn;\n+\t\t}\n+\t}\n+\n+\t/* Nothing matched -- set the default value */\n+\tif (!(slot & EXPIRE_TOTAL))\n+\t\tcb->expire_total = default_reflog_expire;\n+\tif (!(slot & EXPIRE_UNREACH))\n+\t\tcb->expire_unreachable = default_reflog_expire_unreachable;\n }\n \n static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)\n@@ -353,6 +453,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)\n \tstruct cmd_reflog_expire_cb cb;\n \tunsigned long now = time(NULL);\n \tint i, status, do_all;\n+\tint explicit_expiry = 0;\n \n \tgit_config(reflog_expire_config, NULL);\n \n@@ -367,20 +468,18 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)\n \tcb.expire_total = default_reflog_expire;\n \tcb.expire_unreachable = default_reflog_expire_unreachable;\n \n-\t/*\n-\t * We can trust the commits and objects reachable from refs\n-\t * even in older repository. We cannot trust what's reachable\n-\t * from reflog if the repository was pruned with older git.\n-\t */\n-\n \tfor (i = 1; i < argc; i++) {\n \t\tconst char *arg = argv[i];\n \t\tif (!strcmp(arg, \"--dry-run\") || !strcmp(arg, \"-n\"))\n \t\t\tcb.dry_run = 1;\n-\t\telse if (!prefixcmp(arg, \"--expire=\"))\n+\t\telse if (!prefixcmp(arg, \"--expire=\")) {\n \t\t\tcb.expire_total = approxidate(arg + 9);\n-\t\telse if (!prefixcmp(arg, \"--expire-unreachable=\"))\n+\t\t\texplicit_expiry |= EXPIRE_TOTAL;\n+\t\t}\n+\t\telse if (!prefixcmp(arg, \"--expire-unreachable=\")) {\n \t\t\tcb.expire_unreachable = approxidate(arg + 21);\n+\t\t\texplicit_expiry |= EXPIRE_UNREACH;\n+\t\t}\n \t\telse if (!strcmp(arg, \"--stale-fix\"))\n \t\t\tcb.stalefix = 1;\n \t\telse if (!strcmp(arg, \"--rewrite\"))\n@@ -400,6 +499,12 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)\n \t\telse\n \t\t\tbreak;\n \t}\n+\n+\t/*\n+\t * We can trust the commits and objects reachable from refs\n+\t * even in older repository. We cannot trust what's reachable\n+\t * from reflog if the repository was pruned with older git.\n+\t */\n \tif (cb.stalefix) {\n \t\tinit_revisions(&cb.revs, prefix);\n \t\tif (cb.verbose)\n@@ -417,6 +522,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)\n \t\tfor_each_reflog(collect_reflog, &collected);\n \t\tfor (i = 0; i < collected.nr; i++) {\n \t\t\tstruct collected_reflog *e = collected.e[i];\n+\t\t\tset_reflog_expiry_param(&cb, explicit_expiry, e->reflog);\n \t\t\tstatus |= expire_reflog(e->reflog, e->sha1, 0, &cb);\n \t\t\tfree(e);\n \t\t}\n@@ -430,6 +536,7 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)\n \t\t\tstatus |= error(\"%s points nowhere!\", ref);\n \t\t\tcontinue;\n \t\t}\n+\t\tset_reflog_expiry_param(&cb, explicit_expiry, ref);\n \t\tstatus |= expire_reflog(ref, sha1, 0, &cb);\n \t}\n \treturn status;\n-- \n1.5.6.rc3.7.g336d0\n"},{"id":"80048","messageId":"lZpNyxfI-KdPeks7z8vB8LO0LOJTHllWcHbQS34JEY4@cipher.nrlssc.navy.mil","threadId":"13904","inReplyTo":"7vabhne15k.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-06-16T16:30:40Z","receivedAt":"2008-06-16T16:30:40Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Junio C Hamano wrote:\n> しらいしななこ writes:\n> \n>> I apologize for my lack of perfect foresight as the original\n>> author of the command. As I already said, I think expiration\n>> period of reflogs that is configurable for each ref as suggested\n>> earlier by Junio makes sense.\n> \n> You do not need to be overly apologetic.\n\nI whole-heartedly second this.\n\n> ... the\n> way for them to thank you would be to scratch their own itch by filling\n> the remaining 10% to make it work better in their context, not by bitching\n> and quibbling on what the dictionary definition of the word \"stash\" is.\n\nI think you're being a little unfair here on two points:\n\n 1) I think it is a valid point that the name of the command and it's\n subcommand \"save\" have contributed to the confusion by those who were\n not involved in the implementation of the stash feature.\n\n 2) A patch _has_ been offered and there has been no discussion of the\n merits of that patch, only on why the stash should be persistent or not.\n\nYou have suggested two alternatives, one (--keep) was not commented on\nfavorably by anyone, and the other was not really commented on at all.\n\nBesides, the point (for those arguing it) was not that users should\nhave the option to keep stashes, it was that keeping stashes\n_by_default_ is the option of least surprise and doing so modifies the\nstash behavior to match user expectations. So up until now, there has\nbeen no reason for anyone to offer any alternative patch, since \"--keep\"\nis not satisfactory and per reflog expiration _alone_ does not solve what\npeople think the problem is (that stashes expire by default).\n\nYour suggestion of per reflog expiration, along with a default\nconfiguration of never for the stash reflog expiration, _does_ solve\nthe problem. Time will tell if this feature is useful outside of\ncontrolling the stash reflog expiration.\n\n-brandon\n"},{"id":"80051","messageId":"g365ov$u74$2@ger.gmane.org","threadId":"13904","inReplyTo":"lZpNyxfI-KdPeks7z8vB8LO0LOJTHllWcHbQS34JEY4@cipher.nrlssc.navy.mil","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-06-16T16:52:48Z","receivedAt":"2008-06-16T16:52:48Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Brandon Casey wrote:\n\n> Your suggestion of per reflog expiration, along with a default\n> configuration of never for the stash reflog expiration, _does_ solve\n> the problem. Time will tell if this feature is useful outside of\n> controlling the stash reflog expiration.\n\nI think that different expiration periods for regular branches (long),\nremote-tracking branches (short), stash (never), and HEAD (perhaps\nlonges) are a very good idea.\n\nFor example reflog for \"pu\" branch might pin quite a large amount\nof non-interesting objects, protecting these unnecessarily.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"80116","messageId":"alpine.DEB.1.00.0806171000400.6439@racer","threadId":"13904","inReplyTo":"7vy755c0b2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-17T09:05:24Z","receivedAt":"2008-06-17T09:05:24Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 16 Jun 2008, Junio C Hamano wrote:\n\n> From: Junio C Hamano \n> Date: Sun, 15 Jun 2008 23:48:46 -0700\n> Subject: [PATCH] Per-ref reflog expiry configuration\n> \n> In addition to gc.reflogexpireunreachable and gc.reflogexpire, this lets\n> you set gc..reflogexpireunreachable and gc..reflogexpire\n> variables.\n> \n> When \"git reflog expire\" expires reflog entry for $ref, the expiry timers\n> are taken from the first that matches $ref (and if there isn't\n> the global default value is used).\n> \n> For example, you could:\n> \n> \t[gc \"refs/stash\"]\n> \t\treflogexpire = never\n> \t\treflogexpireunreachable = never\n> \n> \t[gc \"refs/remotes/*\"]\n> \t\treflogexpire = 7 days\n> \t\treflogexpireunreachable = 3 days\n> \n> \t[gc]\n> \t\treflogexpire = 90 days\n> \t\treflogexpireunreachable = 30 days\n\nIsn't this overkill? I mean, we could just change git-stash to output a \nwarning:\n\n\tNote: your changes have been stored temporarily. If you need to \n\tkeep them permanently, consider putting them into a branch:\n\n\t\tgit branch stashed-longer stash\n\nDon't get me wrong: I think per-ref reflog expiry is nifty, but it may be \n_too_ nifty, i.e. so complicated only power-users will use it.\n\nCiao,\nDscho\n"},{"id":"80169","messageId":"7vej6v683q.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"alpine.DEB.1.00.0806171000400.6439@racer","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-17T21:54:01Z","receivedAt":"2008-06-17T21:54:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 16 Jun 2008, Junio C Hamano wrote:\n> ...\n> Isn't this overkill? I mean, we could just change git-stash to output a \n> warning:\n>\n> \tNote: your changes have been stored temporarily. If you need to \n> \tkeep them permanently, consider putting them into a branch:\n>\n> \t\tgit branch stashed-longer stash\n\nYou are asking the question to a Wrong Person, as I never asked to have a\nnonexpirable stash, but I would hate such a change to waste four lines\nof my terminal every time I create a new stash.\n\nAlso making a \"branch\" in the \"git branch\" sense (iow, a local branch you\ncan build on top of) is not something you would want anyway, isn't it?\nWhat is the workflow to resume working from there?\n\n\t$ git checkout stashed-longer\n $ git reset --soft HEAD^\n $ work more\n $ git commit\n\nand losing the tip with \"reset --soft\" would be crucial. Otherwise if you\nmake commits on top of it by mistake, you will have a funny merge in the\nhistory behind that commit. IOW\n\n\t$ git checkout stashed-longer\n $ work more\n $ git commit --amend\n\nwould not work.\n\nOf course,\n\n\t$ git stash apply stashed-longer\n\nwould work but that is by accident, as at that point what you are feeding\n\"git stash\" command is not really a name of a ref that is a stash.\n"},{"id":"80225","messageId":"alpine.DEB.1.00.0806181624120.6439@racer","threadId":"13904","inReplyTo":"7vej6v683q.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-06-18T15:25:19Z","receivedAt":"2008-06-18T15:25:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Jun 2008, Junio C Hamano wrote:\n\n> Of course,\n> \n> \t$ git stash apply stashed-longer\n> \n> would work but that is by accident, as at that point what you are feeding\n> \"git stash\" command is not really a name of a ref that is a stash.\n\nIt would not be by accident. It would work because we designed git-stash \nto use refs to store working-directory vs index changes, and this command \nline you wrote was _exactly_ what I intended.\n\nCiao,\nDscho\n"},{"id":"80239","messageId":"7v4p7qzi22.fsf@gitster.siamese.dyndns.org","threadId":"13904","inReplyTo":"alpine.DEB.1.00.0806181624120.6439@racer","subject":"Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-06-18T18:58:29Z","receivedAt":"2008-06-18T18:58:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Tue, 17 Jun 2008, Junio C Hamano wrote:\n>\n>> Of course,\n>> \n>> \t$ git stash apply stashed-longer\n>> \n>> would work but that is by accident, as at that point what you are feeding\n>> \"git stash\" command is not really a name of a ref that is a stash.\n>\n> It would not be by accident. It would work because we designed git-stash \n> to use refs to store working-directory vs index changes, and this command \n> line you wrote was _exactly_ what I intended.\n\nWell, it is. For normal stash oriented operations such as\n\n $ git stash list stashed-longer\n $ git stash apply stashed-longer@{22}\n\nwon't work on them. Only the quoted form works and that _is_ by accident.\n"}]}