2008/6/14 Junio C Hamano <gitster@xxxxxxxxx>: > I think the steps from here on would be: > > - Apply the patch in your message I am responding to, so that a stash > that is kept forever will not pin the unnecessary history behind it in > the repository. As you said there is no reason to make the base commit > (H) actually the same as the commit in the true history --- the only > thing we care about it is its tree object; > > - Design and decide the way to tell git to make stash entries unexpirable > (or maybe have very long expiration period). I am leaning toward a > configuration option that lets you specify expiration period per ref, > rather than marking individual reflog entries as I suggested earlier; > > - Make the default for new repositories' stash reflog expiry period > "never", by setting the above configuration upon "git init". > > None of the above should obviously be in 1.5.6, but I think even the third > step to the change the default would be acceptable in the next 1.6.0 > release. In addition, how about a new stash option "expire", as in: git stash expire --before=2.weeks.ago The default for expire should probably be default expiration period; if set to "never" then a usage message could be printed. I for one would choose "never", so the above would be a simple way of cleaning up if/when too much cruft accumulates. - Eric -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
