0

My use case is that

  1. I have a very large GIT repository created by uidA:gidA with all its files and git index as uidA:gidA
  2. That I have snapshoted/frozen using netapp file system technology aka froze the content of that directory and the git workspace
  3. I "filesystem clone" the snapshot for uidB:gidB. which creates a new workspace instantly with an exact replica of the snapshot, with 1 difference every file/directory is now owned by uidB:gidB.

When I do a "git status" it forces an update to the index, most likely because the files/objects in the index are stored as uidA:gidA, while all the files in the "filesystem cloned" workspace are owned by uidB:gidB and there is a mismatch.

  1. Is there a way to efficiently update some or all the objects/files in the index to uidB:gidB. The default update I suspect actually checks each file before updating the index, which in this case is not needed. So I want to way to blindly update all files in the index to uidB:gidB

  2. OR avoid forcing the index update.

Doing an index update in our very large workspace takes 20+ minutes, on NFS. The workspace is 800GB

JustAG33K
  • 1,403
  • 3
  • 13
  • 28
Sarvi Shanmugham
  • 487
  • 4
  • 13
  • 1
    Git does nothing with uids, gids, etc; it does understand, to a very limited extent, how to manipulate umask, but that's all. For some reason, the index *does* **store** the uid/gid pair, but Git doesn't do anything other than compare them. It seems like it should not even store them (and hence not compare them). You could probably write a program to read and zap the stored uid/gid pairs, but there isn't one in the Git source. – torek Sep 03 '21 at 22:23

1 Answers1

1

The Git command line tools don't let you update this information in the index. However, Git does provide options to control what data is stored in the index.

You can set core.checkstat to minimal to exclude a lot of data, including the UID, GID, device number, and inode number from the index. This is normally included because it's a good way to rapidly detect changes, but in your case you don't want that. You may also need to set core.trustCtime to false if your copy operation doesn't preserve the ctime as well.

Do note, however, that it is not safe to share a working tree across users. Any user who can modify the original working tree can execute arbitrary code as other users who use the working tree or a copy of it by setting configuration. Therefore, this is possible to do, but it is not secure unless you trust the original creator of the working tree to execute arbitrary code on your machine. The only safe thing to do with an untrusted repository is clone or fetch from it.

bk2204
  • 64,793
  • 6
  • 84
  • 100