On Tue, Jul 12, 2016 at 6:01 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > 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. Ok, I started working on automatically pushing back all changes to the shared index when the percentage of entries in linked vs shared indexes is greater than 25% (maybe I will make it configurable later). It is very basic and doesn't work well for now (for one thing it is missing added entries), see: https://github.com/chriscool/git/commits/config-split-index8 Basically I would like a way to count then entries that are only in the linked index without modifying them to be safe, but I have a hard time seeing how I could modify prepare_to_write_split_index() to get that. > 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. I'd like to avoid re-split only on some specific commands as I feel it could lead to bad behavior when none of these specific commands are called but the linked index is growing because of other commands. -- 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