文件所有权不会停留在git分支更改上

Question

Ok so I have an odd problem.

I have a git project with several files. I accidently created, added and committed a file with the root user as the file owner rather than the user which I have set up as the owner for the rest of the project. I merged this file so that it is in both my master branch as well as in my dev branch. In both branches it reads that root is the owner of this file.

So with my master branch checked out, I ran chown user:user file.txt to set the file to the usual user for the rest of the project. After doing an ls -l I see that the file now shows that "user" is now the owner and group. Great!

Now if I go and checkout the dev branch and run an ls -l it shows the file is owned by root again. And if I checkout the master branch again it now shows that the file owner has changed back to being the root user rather than "user".

I tried many things, but every time I checked out a branch that contained the file, the user was always set as "root" no matter how hard I tried to set it as "user".

Am I doing something wrong? git shouldn't be storing the owner of the file, but yet it seems to be ignoring my ownership changes.

Thanks.

Answer 1

It is not possible to create a file that's owned by root, unless you're root yourself[1]. This is a fundamental security issue that predates even Linux.

Stop using the root userid when working with your git repository, and the problem will go away.

Do a recursive chown -R on your entire git repository. Then always execute git commands while logged in as the correct user.

[1] Yes, you can rename root-owned files if you have write permissions on the directory. But git doesn't do that, when checking out files.

Answer 2

It turns out that I had to push a commit to the remote repository for the ownership changes to stick. Not sure why this was. And yes I know don't use the root user etc etc. It was a stupid little mistake, one which I was attempting to remedy.