Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Am 4/15/2010 9:40, schrieb Junio C Hamano: >> Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: >> >>> Does not help what? What is the problem? >> >> You will lose the record from HEAD reflog that records the fact that you >> were at the tip of "next" less than "reflogexpire" but more than >> "reflogexpireunreachable" time ago, if you run "gc" while on "master". >> >> Such a pruning does not have much to do with the real reason why >> expireunreachable would be a useful thing (namely, to prune failed >> histories that have been rewound away faster than the history that >> survived from reflog of individual branches). > > But what is the benefit? That is a funny thing to ask. Since when not losing information is a lower priority? > We expire reflogs so that we can garbage-collect objects. I am tempted to say "Wrong!", but would stop at saying "We seem to have differing opinions" for now. A reflog consists of entries, each of which records how you got to the current history by pointing to different commit objects. Some entries matter more than others do. Dead-end experiments stop mattering faster than others. It is these _entries_ that we expire, because keeping them indefinitely is a wasteful clutter. Removing stale objects is not a goal; objects are removed merely as an effect of them becoming stale after no refs and reflog entries that matter point at them. -- 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