On Tue, Jul 12, 2016 at 9:04 AM, Christian Couder <christian.couder@xxxxxxxxx> wrote: > On Mon, Jul 11, 2016 at 8:27 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder >> <christian.couder@xxxxxxxxx> wrote: >>> Everytime split index is turned on, it creates a "sharedindex.XXXX" >>> file in the git directory. This makes sure that old sharedindex >>> files are removed after a new one has been created. >> >> Hmm it's one-way link, we don't know how many index files use this >> shared index file, how can you be sure nobody else will need it? I'm >> thinking about temporary indexes. If a temp index is created, saved on >> disk, and use delete the shared index file, the real, main index may >> become useless. Temp index will most likely replace the main index >> (git commit) but if a failure happens, we can't fall back. > > Isn't there a way to scan all the current indexes (temp or not) to see > which shared indexes they need? No. People could create an index file anywhere in theory. So you don't know how many index files there are. >> A safer approach is "touch" the shared index every time a linked index >> is used, then we can delete shared indexes with old mtime, older than >> a grace period, in git-prune (or here). > > Maybe old linked indexes could be converted after some time to use a > newer shared index, so that we can get rid of the old shared indexes. > That seems safer than just deleting old linked indexes. It really depends. If the shared part is too small for old indexes, we might as well unsplit them. In practice though, the only long-term index file is $GIT_DIR/index. If we don't delete old shared index files too close to their creation time, temp index files will go away. -- 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