On Thu, 15 Apr 2010, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxxxxxx> writes: > > > Again, keeping reflogs 90 days for stuff that is _already_ reachable > > through existing refs is much less useful than keeping otherwise > > unreachable stuff 90 days. So I still don't see the point of this > > eagerness to prune deleted stuff faster. > > Hmph, I honestly cannot care about this very much without knowing where > this is going, because the distinction between the two has been with us > practically forever, since the day one of "reflog expire". Argh. OK you can paint me confused. I was mixing up --expire-unreachable with --stale-fix. Having my head screwed back on now, I do agree with Jeff when he says: |I think another way of addressing the same problem would be to redefine |"reachable" in this context as "reachable from any current ref". Otherwise having a special exception for HEAD would effectively make those unreachable objects non prunable until the HEAD reflog entries are themselves expired. > Is there any constructive conclusion you are aiming for? For example, is > a proposal to update the default value of both to 90 or 120 days coming? I think that the default value for reflogexpireunreachable should be the value of reflogexpire, and not 30 days. In my opinion, having a shorter expiration period for non reachable objects by default makes little sense. Again, it is for the non reachable objects that the reflog is most useful. Nicolas -- 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