Some scalar clones are putting GVFS packs in local object dir instead of shared object dir about git HOT 6 CLOSED

The agents in question are actually OMR-based (and technically Server 2022 instead of Win11). We have 1JS agents too, but haven't dug in there because they aren't impacted like our OMR agents are.

from git.

I figured this one out. When running scalar clone initially, we clone by specifying a path like c:\foo, with the problem itself being the lowercase c. The lowercase c persists itself all the way through into the repo's config:

[gvfs]
  sharedCache = c:\\.scalarCache/id_ba47400f-eebe-4850-a8bf-ef694ef81414

This becomes problematic in this code, which uses strcmp instead of something like stricmp:

odb->path above uses C: instead of c:, the comparison doesn't match, and it falls back to .git/objects.

from git.

A possible direction to be as safe as possible is to update the incremental-repack maintenance step to move objects from .git/objects into the shared object cache.

My major concern about this strategy is that .git/objects can very well contain objects that have not originated from the remote repository, and one single ill-considered re-creation of the shared object cache might very well wipe out objects that will now be irretrievably lost.

from git.

@AtOMiCNebula great find! This strcmp() should be replaced with fspathcmp(). Would you mind opening a PR that makes it so?

from git.

One thing @AtOMiCNebula pointed out is that we want to make sure that users in this state are getting into a better state when the config is parsed correctly.

A possible direction to be as safe as possible is to update the incremental-repack maintenance step to move objects from .git/objects into the shared object cache. Move packs wholesale to keep their prefetch-<timestamp>... names. This could be a helpful feature, anyway, since the local object store isn't being repacked in Scalar clones with a shared object cache.

from git.

I created #660 to fix this.

from git.