On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder <christian.couder@xxxxxxxxx> wrote: > Future work > ~~~~~~~~~~~ > > One thing that is probably missing is a mechanism to avoid having too > many changes accumulating in the (split) index while in split index > mode. The git-update-index documentation says: > > If split-index mode is already enabled and `--split-index` is > given again, all changes in $GIT_DIR/index are pushed back to > the shared index file. > > but it is probably better to not expect the user to think about it and > to have a mechanism that pushes back all changes to the shared index > file automatically when some threshold is reached. The threshold could > be for example when $GIT_DIR/index size is larger than 25% of the > shared index size. Opinions, test results or test ideas are welcome on > this. Oh yes I would like something like this. I stuck to the basics because as you see you need to define some criteria to re-split again, but without experimenting on real repos, I could just have gone the wrong way. Index file size or the percentage of entries in linked/shared indexes are two good candidates. You can also just re-split on commands that likely lead to increasing linked index size a lot (maybe git-reset), or run long enough that some extra processing won't get noticed. For example git-gc should definitely re-split if this feature is on, but I can't say if it's often enough. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html