On Fri, Jan 12, 2018 at 03:44:26PM +0100, Ævar Arnfjörð Bjarmason wrote:
> More generally, the reason we even have the 2 week limit is to pick a
> good trade-off between performance and not losing someone's work that
> they e.g. "git add"-ed but never committed.
>
> I'm suggesting (but don't know if this is worth it, especially given
> Jeff's comments) that one smarter approach might be to track where the
> objects came from (e.g. by keeping reflogs for deleted upstream branches
> for $expiry_time).
I don't think reflogs would help here. We consider reflog'd objects as
"reachable". So you'd still have something like this:
1. You delete a branch. Reflog still mentions its commits.
2. You run gc (or auto-gc). Those objects are still retained in the
main pack due to the reachability rule. This may happen multiple
times, and each time their "timestamp" is updated, because it is
really just the timestamp of the containing pack.
3. 30 days later, you run another gc. The reflog is now past its
expiration and is deleted, and now those objects are unreachable.
This gc turns them loose, but it still considers them "recent" as
of the last gc you ran, due to the timestamp thing above.
-Peff
