On Tue, Nov 1, 2016 at 8:19 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Christian Couder <christian.couder@xxxxxxxxx> writes: > >> +splitIndex.maxPercentChange:: >> + When the split index feature is used, this specifies the >> + percent of entries the split index can contain compared to the >> + whole number of entries in both the split index and the shared >> + index before a new shared index is written. >> + The value should be between 0 and 100. If the value is 0 then >> + a new shared index is always written, if it is 100 a new >> + shared index is never written. > > Hmph. The early part of the description implies this will kick in > only when some other conditions (i.e. the bit in the index or the > other configuration) are met, but if this disables the split index > when it is set to 0, would we even need the other configuration > variable? IOW, perhaps we can do without core.splitIndex? I think it is easier for user to be able to just set core.splitIndex to true to enable split-index. If we ask them to instead set splitIndex.maxPercentChange to a "reasonable value like 20" to enable it, they will start to wonder why 20 and not 50 or 100 and might be unnecessarily confused. Also it might be good to make it possible to have other values than "true" and "false" for core.splitIndex in the future. For example if we decide to first enable split-index only on $GIT_DIR/index, we might later want an "everywhere" or "always" value for core.splitIndex if we find a way to enable it on other indexes. We might also want an "auto" mode in the future when split-index will work really well, so that it can be turned on automatically on all the repos where it makes sense (like when the index contains more than 10000 entries for example). >> + By default the value is 20, so a new shared index is written >> + if the number of entries in the split index would be greater >> + than 20 percent of the total number of entries. >> + See linkgit:git-update-index[1].