しらいしななこ <nanako3@xxxxxxxxxxxxxx> writes: > I apologize for my lack of perfect foresight as the original > author of the command. As I already said, I think expiration > period of reflogs that is configurable for each ref as suggested > earlier by Junio makes sense. You do not need to be overly apologetic. It's not your fault that the way you originally scratched your own itch is already 90% useful to others in different context of theirs but with 10% "caveat emptor". Others owe kudos to you for what they're given, and the way for them to thank you would be to scratch their own itch by filling the remaining 10% to make it work better in their context, not by bitching and quibbling on what the dictionary definition of the word "stash" is. > But changing the default expiration "never" for stash has its > own problem and I think we need to modify the way a stash entry > is created to solve it. > ... > If you do not expire stash forever, you will keep the history > behind the commit H. This is unnecessary and is problematic > particularly if you rebase your branches frequently. > > In order to apply a stash, all you need is the tree of the three > commits contained in this structure. You do not need the > history behind commit H. > > The following is a trial patch to change how a stash is recorded. > With this patch I do not think we will keep unnecessary commits > behind H in the repository even when a stash is kept forever. Keeping stashes indefinitely is a relatively easy change (even though there may need design discussions on the cleanest way to do so) but nobody so far seemed to have thought about the ramifications of doing so. I am glad somebody is thinking one step ahead, and I think what you raised is a valid concern. Crufts from rebases will usually be purged from repository thanks to reflog autoexpiration, but if somebody keeps a stash that was made on a commit that has long been rebased away, it will keep the rebased commits pinned to the repository, and we are talking about indefinite retention here. People should get worried. I suspect this won't be a huge issue, but the only reason behind that suspicion is because I expect people won't have insane number of rebases nor keep insane number of stash entries, so the extra cruft that is kept behind the stash entries won't be insanely large. But people are known to be insane enough to break my expectations, so I'd say we should make things safer before we make the change to keep stashes forever by default. I think the steps from here on would be: - Apply the patch in your message I am responding to, so that a stash that is kept forever will not pin the unnecessary history behind it in the repository. As you said there is no reason to make the base commit (H) actually the same as the commit in the true history --- the only thing we care about it is its tree object; - Design and decide the way to tell git to make stash entries unexpirable (or maybe have very long expiration period). I am leaning toward a configuration option that lets you specify expiration period per ref, rather than marking individual reflog entries as I suggested earlier; - Make the default for new repositories' stash reflog expiry period "never", by setting the above configuration upon "git init". None of the above should obviously be in 1.5.6, but I think even the third step to the change the default would be acceptable in the next 1.6.0 release. -- 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
