On Tue, Dec 27, 2016 at 8:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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? Yeah, I agree it is better for end users. I will use what you suggest. >> + 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."? Yeah, I also agree it is better and will use that.