Hello,
When on a CIFS filesystem a git checkout does not replicate the executable
flag from the repository:
$ git clone git://git/abettersqlplus
Cloning into 'abettersqlplus'...
remote: Counting objects: 522, done.
remote: Compressing objects: 100% (342/342), done.
remote: Total 522 (delta 166), reused 522 (delta 166)
Receiving objects: 100% (522/522), 82.40 KiB, done.
Resolving deltas: 100% (166/166), done.
$ ls -l abettersqlplus/absp.py
-rw-rw-r-- 1 aesser geneity 45860 May 29 14:46 abettersqlplus/absp.py
Subsequently git status reports the file as changed:
$ cd abettersqlplus/
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: absp.py
#
no changes added to commit (use "git add" and/or "git commit -a")
If I set the x-flag manually, all is well:
$ chmod +x absp.py
$ git status
# On branch master
nothing to commit (working directory clean)
This problem doesn't occur on ext3 or NFS file systems. Client is Ubuntu
12.04 with git version 1.7.9.5. CIFS is exported from Ubuntu 12.04 with
Samba version 3.6.3.
Since git recognises the x-flag on this CIFS file system, shouldn't it also
be able to set it on checkout?
Many thanks,
Andre Esser
On Wed, May 29, 2013 at 4:16 PM, Andre Esser [off-list ref] wrote:
Hello,
When on a CIFS filesystem a git checkout does not replicate the executable
flag from the repository:
$ git clone git://git/abettersqlplus
Cloning into 'abettersqlplus'...
remote: Counting objects: 522, done.
remote: Compressing objects: 100% (342/342), done.
remote: Total 522 (delta 166), reused 522 (delta 166)
Receiving objects: 100% (522/522), 82.40 KiB, done.
Resolving deltas: 100% (166/166), done.
$ ls -l abettersqlplus/absp.py
-rw-rw-r-- 1 aesser geneity 45860 May 29 14:46 abettersqlplus/absp.py
Subsequently git status reports the file as changed:
$ cd abettersqlplus/
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: absp.py
#
no changes added to commit (use "git add" and/or "git commit -a")
If I set the x-flag manually, all is well:
$ chmod +x absp.py
$ git status
# On branch master
nothing to commit (working directory clean)
This problem doesn't occur on ext3 or NFS file systems. Client is Ubuntu
12.04 with git version 1.7.9.5. CIFS is exported from Ubuntu 12.04 with
Samba version 3.6.3.
Since git recognises the x-flag on this CIFS file system, shouldn't it also
be able to set it on checkout?
You might want to check out the core.filemode configuration variable.
On 2013-11-20 10:51, Erik Faye-Lund wrote:
On Wed, May 29, 2013 at 4:16 PM, Andre Esser [off-list ref] wrote:
quoted
Hello,
When on a CIFS filesystem a git checkout does not replicate the executable
flag from the repository:
$ git clone git://git/abettersqlplus
Cloning into 'abettersqlplus'...
remote: Counting objects: 522, done.
remote: Compressing objects: 100% (342/342), done.
remote: Total 522 (delta 166), reused 522 (delta 166)
Receiving objects: 100% (522/522), 82.40 KiB, done.
Resolving deltas: 100% (166/166), done.
$ ls -l abettersqlplus/absp.py
-rw-rw-r-- 1 aesser geneity 45860 May 29 14:46 abettersqlplus/absp.py
Subsequently git status reports the file as changed:
$ cd abettersqlplus/
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: absp.py
#
no changes added to commit (use "git add" and/or "git commit -a")
If I set the x-flag manually, all is well:
$ chmod +x absp.py
$ git status
# On branch master
nothing to commit (working directory clean)
This problem doesn't occur on ext3 or NFS file systems. Client is Ubuntu
12.04 with git version 1.7.9.5. CIFS is exported from Ubuntu 12.04 with
Samba version 3.6.3.
Since git recognises the x-flag on this CIFS file system, shouldn't it also
be able to set it on checkout?
You might want to check out the core.filemode configuration variable.
Thanks, but unfortunately that only suppresses the error message, it
still doesn't set the x-flag when it should.
Andre