Patrick Steinhardt <ps@xxxxxx> writes: > I'd really like to start thinking about reftables as the default > backend. They fix filesystem-specific issues, compress better, are more > efficient in most (not all) use cases, sometimes significantly so, have > better properties when it comes to repository maintenance. We could for > example make "features.experimental" enable the reftable backend by > default and add a note to the Git 3.0 breaking changes in that spirit. I am a bit surprised that there is no reference to reftable in the breaking changes document ;-) I am all for allowing users to opt into it dynamically, and feature.experimental is the ideal mechanism to do so. Currently it sets four configuration variables, and making it five would not make it too scary for adventurous users. > I bet there's also tons of scripts out there that just reach into the > filesystem to do stuff, but that's something that we cannot really help > with. I thought you've done enough to make sure that common things people would want to do by direct access to the .git/refs/ hierarchy can be easily done with plumbing commands instead, so it would probably be a matter of writing and publicizing the "how to migrate to the world where you cannot write into files under .git/refs/ directory" document? Thanks.
