Re: [RFD] server-info to help clients

The management of multiple packs and strategy of deciding when to create the next incremental (be it throw-away or permanent) is something I am not particularly interested in at this moment, and as you correctly pointed out, the "single throw-away pack" is an example of _bad_ strategy [*1*]. I am more interested in designing a concise way to express what the server side has (after applying such packing/repacking strategy) to help clients coming over a dumb transport.

One thing that I forgot to mention is that there is another per-repository information "$repo/info/revinfo". This lists all the commit ancestry reachable from "$repo/refs", and is needed for clients to find out the closest commit from the very tip of branches, which are likely not packed yet, that appears as a head in "$repo/objects/info/pack" and go from there.

[Footnote]

*1* As I said, I am not interested in thinking about this at this moment, but I suspect a scheme that employs the base pack, permanent incrementals, and N new throw-aways every day for the N-th day of the month may work reasonably well.

On the N-th day of the month, you create incrementals relative to what existed on the N-1th, N-2th, ..., 1st of the month. At the end of the day, create N+1 new throw-aways for the N+1th day of the month (you can garbage collect older days' throw-away incrementals whenever you like). At the end of the month, you mark the throw-away incremental that is relative to the beginning of the month as the latest permanent incremental.

Bootstrappers can slurp base, permanent incremental and the throwaway for today that is relative to the last permanent incremental. Updaters can pick the one relative to the day they updated last time.