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

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

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html