<20170223155046.e7nxivfwqqoprsqj@LykOS.localdomain>,
<CA+EOSBncr=4a4d8n9xS4FNehyebpmX8JiUwCsXD47EQDE+DiUQ@mail.gmail.com>.
+* The default storage format for references in newly created repositories will
+ be changed from "files" to "reftable". The "reftable" format provides
+ multiple advantages over the "files" format:
++
+ ** It is impossible to store two references that only differ in casing on
+ case-insensitive filesystems with the "files" format. This issue is common
+ on Windows and macOS platforms. As the "reftable" backend does not use
+ filesystem paths to encode reference names this problem goes away.
+ ** Similarly, macOS normalizes path names that contain unicode characters,
+ which has the consequence that you cannot store two names with unicode
+ characters that are encoded differently with the "files" backend. Again,
+ this is not an issue with the "reftable" backend.
+ ** Deleting references with the "files" backend requires Git to rewrite the
+ complete "packed-refs" file. In large repositories with many references
+ this file can easily be dozens of megabytes in size, in extreme cases it
+ may be gigabytes. The "reftable" backend uses tombstone markers for
+ deleted references and thus does not have to rewrite all of its data.
+ ** Repository housekeeping with the "files" backend typically performs
+ all-into-one repacks of references. This can be quite expensive, and
+ consequently housekeeping is a tradeoff between the number of loose
+ references that accumulate and slow down operations that read references,
+ and compressing those loose references into the "packed-refs" file. The
+ "reftable" backend uses geometric compaction after every write, which
+ amortizes costs and ensures that the backend is always in a
+ well-maintained state.
+ ** Operations that write multiple references at once are not atomic with the
+ "files" backend. Consequently, Git may see in-between states when it reads
+ references while a reference transaction is in the process of being
+ committed to disk.
+ ** Writing many references at once is slow with the "files" backend because
+ every reference is created as a separate file. The "reftable" backend
+ significantly outperforms the "files" backend by multiple orders of
+ magnitude.
+ ** The reftable backend uses a binary format with prefix compression for
+ reference names. As a result, the format uses less space compared to the
+ "packed-refs" file.
++
+Users that get immediate benefit from the "reftable" backend could continue to
+opt-in to the "reftable" format manually by setting the "init.defaultRefFormat"
+config. But defaults matter, and we think that overall users will have a better
+experience with less platform-specific quirks when they use the new backend by
+default.
++
+A prerequisite for this change is that the ecosystem is ready to support the
+"reftable" format. Most importantly, alternative implementations of Git like
+JGit, libgit2 and Gitoxide need to support it.
+
=== Removals
* Support for grafting commits has long been superseded by git-replace(1).