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 nneul@xxxxxxxxxxxxx
Neulinger Consulting (573) 612-1412
