4

I was working on a single file in a branch (Branch-A), committed my code and pushed up my changes. I then checked out a new branch (Branch-B) did some work but noticed I was getting changes on the same file I worked on in Branch-A.

I ran git checkout -- /file.php to revert the changes, but got the message:

error: unable to unlink old 'file.php' (Permission denied)

Googling the issue, I find a lot of StackOverflow answers saying to change the file's permissions, which I tried:

chmod ug+w file.php

and

chmod 777 file.php

But still I get the same issue with the same error message.

Would anyone know what this is or what I could do next?

MeltingDog
  • 14,310
  • 43
  • 165
  • 295
  • Try using root permission `sudo chmod 777 file.php` or check if you have appropriate git user for checking out the repository – amrs-tech Aug 30 '19 at 04:28
  • 2
    On a Linux or Unix system, inspect the permissions of the *containing directory*. You must be able to write the containing directory to remove a file within it. – torek Aug 30 '19 at 05:39
  • Yes, you are right @torek. Would you like to make that an answer? – MeltingDog Sep 02 '19 at 00:05
  • @amrs-tech: If that were the problem, you would have gotten an error message on the original non-root `chmod`. Also, `777` is excessive; there's no point in giving all users read, write, and execute permission. `644` or `755` is enough (the latter only if it needs to be executable). – Keith Thompson Sep 02 '19 at 00:32

2 Answers2

0

Depending on your OS, check first the rights associated with that file

cd /path/to/repo
# assuming file.php is at the root directory of the repository
ls -alrth file.php
git checkout -- file.php

(try the checkout without the /)

As I mentioned here, make sure the file is not opened by any other tool/editor.
See also this answer, and try setting git config core.sharedRepository true inside your repository.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

On a Unix or Linux based system, the ability to remove a file—or create one, for that matter—is typically controlled by the permissions of the file's containing directory. Hence file.php depends on the permissions of the work-tree (in this case ., or the path to it):

$ ls -ld
drwxr-xr-x 12 root root 4096 ...

or:

# in a different directory
$ ls -ld
drwxrwxr-x 46 vagrant vagrant 4096 Aug 29 23:34 .

for instance.

In the former case, the directory is owned by root and is writable only by root so only the super-user can create or remove files. In the second case, the directory is owned by user vagrant and group vagrant, and is both user- and group-writable, so user vagrant may create or delete files, and so may any user who is a member of the vagrant group (which on this particular system is only the user vagrant anyway).

If you, as a user, do not have write-access to the containing directory, you can change the ownership (user and/or group) and mode as necessary, or do operations as the super-user (who generally can do anything even if the permissions are set to deny access to root) via sudo. It's wise to limit the amount of work done as the super-user.

torek
  • 448,244
  • 59
  • 642
  • 775