Christian Couder <christian.couder@xxxxxxxxx> writes: > Signed-off-by: Christian Couder <chriscool@xxxxxxxxxxxxx> > --- > Documentation/config.txt | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/config.txt b/Documentation/config.txt > index e0f5a77980..24e771d22e 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -2786,6 +2786,17 @@ splitIndex.maxPercentChange:: > than 20 percent of the total number of entries. > See linkgit:git-update-index[1]. > > +splitIndex.sharedIndexExpire:: > + When the split index feature is used, shared index files with > + a mtime older than this time will be removed when a new shared As end-user facing documentation, it would be much better if we can rephrase it for those who do not know what a 'mtime' is, and it would be even better if we can do so without losing precision. I think "shared index files that were not modified since the time this variable specifies will be removed" would be understandable and correct enough? > + index file is created. The value "now" expires all entries > + immediately, and "never" suppresses expiration altogether. > + The default value is "one.week.ago". > + Note that each time a new split-index file is created, the > + mtime of the related shared index file is updated to the > + current time. To match the above suggestion, "Note that a shared index file is considered modified (for the purpose of expiration) each time a new split-index file is created based on it."? > + See linkgit:git-update-index[1]. > + > status.relativePaths:: > By default, linkgit:git-status[1] shows paths relative to the > current directory. Setting this variable to `false` shows paths