Hi, Duy Nguyen wrote: > On Wed, Jan 17, 2018 at 4:42 AM, Brandon Williams <bmwill@xxxxxxxxxx> wrote: >> IIUC Split index is an index extension >> that can be enabled to limit the size of the index file that is written >> when making changes to the index. It breaks the index into two pieces, >> index (which contains only changes) and sharedindex.XXXXX (which >> contains unchanged information) where 'XXXXX' is a value found in the >> index file. If we don't do anything fancy then these two files live >> next to one another in a repository's git directory at $GIT_DIR/index >> and $GIT_DIR/sharedindex.XXXXX. This seems to work all well and fine >> except that this isn't always the case and the read_index_from function >> takes this into account by enabling a caller to specify a path to where >> the index file is located. We can do this by specifying the index file >> we want to use by setting GIT_INDEX_FILE. [...] >> In this case if i were to specify a location of an >> index file in my home directory '~/index' and be using the split index >> feature then the corresponding sharedindex file would live in my >> repository's git directory '~/project/.git/sharedindex.XXXXX'. So the >> sharedindex file is always located relative to the project's git >> directory and not the index file itself, which is kind of confusing. >> Maybe a better design would be to have the sharedindex file located >> relative to the index file. > > That adds more problems. Now when you move the index file around you > have to move the shared index file too (think about atomic rename > which we use in plenty of places, we can't achieve that by moving two > files). A new dependency to $GIT_DIR is not that confusing to me, the > index file is useless anyway if you don't have access to > $GIT_DIR/objects. There was always the option to _not_ split the index > when $GIT_INDEX_FILE is specified, I think I did consider that but I > dropped it because we'd lose the performance gain by splitting. Can you elaborate a little more on this? At first glance, it seems simpler to say "paths in index extensions named in the index file are relative to the location of the index file" and to make moving the index file also require moving the shared index file, exactly as you say. So at least from a "principle of least surprise" perspective I would be tempted to go that way. It's true that we rely on atomic rename in plenty of places, but only within a directory. (Filesystem boundaries, NFS, etc mean that atomic renames across directories are a lost cause.) Fortunately index files (including temp index files used by scripts) tend to only be in $GIT_DIR, for exactly that reason. So I am wondering if switching to index-file-relative semantics would be an invasive move and what the pros and cons of such a move are. Thanks, Jonathan
