Daniel Höpfl <daniel@xxxxxxxxx> writes:
> Hello,
>
> I recently (very recently: yesterday) started using git. I switched from
> Bazaar, that required me to have a file system that supports the executable
> flag (as it always stores this flag based on what the file system says).
> FAT does not support the executable flag.
That is why there is `core.fileMode` config variable, see git-config(1)
manpage:
core.fileMode
If false, the executable bit differences between the index and the
working copy are ignored; useful on broken filesystems like FAT. See
git-update-index(1).
The default is true, except git-clone(1) or git-init(1) will probe
and set core.fileMode false if appropriate when the repository is
created.
Didin't git detect that it was on such filesystem?
[...]
> I think that my file system is right (of course ;-) ): A file that is not
> writable must not be renamed (arguable as the name could be seen as the
> content of the containing directory) and it must not be deleted.
Not true. Whether file can be renamed or deleted is governed by
permissions in directory that contains given file, not the file itself
(at least on POSIX). If I understand things correctly, of course.
Note that git doesn't store full permissions, in particular read/write
permissions, only executable bit and "is symlink" thing.
--
Jakub Narebski
Poland
ShadeHawk on #git
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html