On Sat, Sep 05, 2020 at 08:18:40PM +0200, Jakub Narębski wrote: > Hello, > > On Sat, 5 Sep 2020 at 20:01, Taylor Blau <me@xxxxxxxxxxxx> wrote: > > But the real issue is that commit-graph files generated with new > > clients would suddenly be unreadable by old clients. > > Actually it is, at least in the form that I have proposed. The Bloom filter > which has all bits set to zero would for every possible path reply that > the path is not in set. Old clients would therefore work without changes. > Therefore this is good representation of no-changes Bloom filter. > > The Bloom filter which has all bits set to one would for every possible > path reply that the path is maybe in set. This is a good alternative > representation of too-many-changes Bloom filter. Again, old clients > would work without changes. That's a very interesting thought. To be honest, I'm not crazy about generating our own Bloom filters that have special meaning (i.e., that even though they are interpreted the same way as any other filter, they are specially-crafted to carry a certain meaning). Your proposal also means that commit-graph files are going to get bigger, which is something that you may or may not care about. On the other hand, it does get rid of the BFXL chunk, which certainly isn't the most elegant thing. I don't know. I think my biggest objection is the size: we use the BIDX chunk today to avoid having to write the length-zero Bloom filters; your scheme would force us to write every filter. On the other hand, we could continue to avoid writing length-zero filters, so long as the commit-graph indicates that it knows this optimization. Stolee: what do you think? > Best, > -- > Jakub Narębski Thanks, Taylor
