What I'm meaning is - why does it need to write the index back out to disk?
From looking at the code in builtin/commit.c it looks like it takes a lock on the index, collects the status, and then unconditionally rewrites the index file.
I'm proposing that the update_index_if_able call not actually be issued if it would result in a ownership change on the underlying file - such as a simple case of root user or other privileged account issuing 'git status' in a directory.
I understand completely that it would be expected to be altered if the privileged user did a commit/add or any other operation that was inherently a 'write' operation, but doesn't seem like status should be one of those cases.
-- Nathan On 11/22/17 9:30 AM, Santiago Torres wrote:
Hi Nathan. Do you mean git-status writing an index file? What would you suggest for git-status to compute which files have changed without modifying an index-file? Or are you suggesting git-status to fail if the index file doesn't belong to the user-id who invoked the command... Thanks, -Santiago
-- ------------------------------------------------------------ Nathan Neulinger nn...@neulinger.org Neulinger Consulting (573) 612-1412
