Quoting Junio C Hamano <gitster@xxxxxxxxx>:
> I do not personally care too deeply about the "keep" approach. An easier
> to explain (and perhaps easier to implement, too) alternative would be to
> have a per-ref configuration variable that specifies the reflog retention
> period per ref, e.g. "git config reflog.refs/stash.expire never".
I think I am primarily responsible for this auto expiration
behavior of git-stash command. The original use case that led
to my git-save script was only about very short-term use. To
tell you the truth, I did not even realize myself that I can use
stash@{<<number>>} to refer to more than one states until
Johannes Schindelin pointed it out to me. It was only about
saving the current state once, and that proves it was about very
short-term use and nothing else.
But I think git-stash may have outgrown the original motivation.
Configurable expiration period per reflog like you suggested
sounds like the most sane solution to the issue to me. I think
that approach is especially attractive because it can kill a few
birds with the same stone. You can configure remote tracking
branches' logs to expire much sooner than your own branches'
ones, for example.
But I think "reflog.refs/stash.expire" you mentioned above is a
bad name. Because the default expiration period is configured
with "gc.reflogexpire", it would be better to make the variable
name start with "gc".
By the way, I sent a documentation patch to git-stash but did
not hear any response. Was there anything wrong with it?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com/tag/3
--
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
