As stated in the title,
what do they mean:
An experimental "version 4" format of the index file has been introduced to reduce on-disk footprint and I/O overhead
More importantly, is there a risk in losing backwards compatibility with this change, or could this change corrupt the repository?
Doing some testing suggests that it's backwards compatible and did not reveal any adverse effects.
Could somebody please clarify what this change actually is to msysgit 1.7.11?
There is no issue of compatibility here (between msysgit and git, or with previous revision of Git), as this is the same modification than in git repo itself (and the official Git repo doesn't mention any compatibility issue).
See, in the git repo the file Documentation/technical/index-format.txt
about the GIT index format:
(Version 4) In version 4, the entry path name is prefix-compressed relative to the path name for the previous entry (the very first entry is encoded as if the path name for the previous entry is an empty string).
At the beginning of an entry, an integerN
in the variable width encoding (the same encoding as the offset is encoded forOFS_DELTA
pack entries; see pack-format.txt) is stored, followed by a NUL-terminated stringS
.
RemovingN
bytes from the end of the path name for the previous entry, and replacing it with the stringS
yields the path name for this entry.
1-8 nul bytes as necessary to pad the entry to a multiple of eight bytes while keeping the name NUL-terminated.
(Version 4) In version 4, the padding after the pathname does not exist.
So this is really internal management of the index entry, which doesn't prevent a git (1.7.11 or any other version) to clone / read a remote repo.
It aims only to optimize the "entry path name" representation.