Re: [RFC/PATCH 8/8] read-cache: unlink old sharedindex files

On Tue, Jul 12, 2016 at 9:04 AM, Christian Couder
[off-list ref] wrote:

On Mon, Jul 11, 2016 at 8:27 PM, Duy Nguyen [off-list ref] wrote:

quoted

On Mon, Jul 11, 2016 at 7:22 PM, Christian Couder
[off-list ref] wrote:

quoted

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.

quoted

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