I'm working on an embedded Linux project. Our build process makes an image that gets flashed to a device. Many of our files require root ownership for the system to work correctly. I ran into a problem when I tried to pull and some of those files were modified - git couldn't write those files, so did reset hard and did sudo pull. Then when I switched branches, it said "unable to unlink..." for all those files, but it switched branches anyway, then when I tried to switch back to the branch it wouldn't let me because I had local changes.
So I'm not doing something right; what is the correct way to deal with this?
To build on Karmastan's answer, the magic words here are "build script".
Files in git don't have to look like the deployment versions. You don't deploy .c files -- you compile them first. Likewise some config files can go through a build process before being deployed/installed, also.
I'm not sure I understand why some files must be
chowne
'd root. Intuitively I'd guess your problem is the dependence on the owner, not that Git doesn't store ownership. What you can do ischown
in you your build.The easiest way (if it's possible) would be to not do any operations (cloning etc) as root, because that leads to the other user not being able to work with the files.
An alternative would be using
git init --shared
to set up shared (group or all) permissions for the repository, followed by agit remote add origin http://host/repo.git
and agit pull origin master
. Which is basically a clone with less strict permissions.I would structure your system so that the source files don't care what owner they are. You can check these in and out of git without worrying what permissions they have or who the owner is (especially since "owner" isn't meaningful across all the systems a git deployment is likely to serve).
When you want to generate the embedded image, copy everything to a new directory and then set the permissions as you need.