Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)
- From
David Chmelik <davidnchmelik@gmail.com>
- Date
- Jul 23, 2022, 00:25 UTC
- Message-ID
- <ccbc1e81-b406-9e73-7aa5-956ffae7074b@gmail.com>
- In-Reply-To
- <CAPx1Gvc6ci1CjhL-zjwqkR=4o2yQTrT0V_Hb9bUBNuaBn47M8A@mail.gmail.com>
On 7/22/22 10:40 AM, Chris Torek wrote:
Show 12 quoted lines
> On Fri, Jul 22, 2022 at 6:24 AM David Chmelik <dchmelik@gmail.com > <mailto:dchmelik@gmail.com>> wrote: > > Ownership, permissions are different: one can own files yet have zero > permission to write/delete and be denied that. ... > > > All true. But Git has no control over, or affect on these: Git does > not attempt to affect ownership or permission of any build products > at all. Git only attempts to affect the execute permission of > specific files as directed by the committed file mode (and provided > `core.filemode` is enabled).
Not even projects' .git* subdirectories? They typically are/become user-non-writable though deletable with several/many confirmations so I usually sudo (recommended against). I'd rather opt-out of .git* subdirectories for every clone.
> [...] If you're using Samba/CIFS or other ACL-based file servers [...]
I don't know what those are (other than once tried Samba to transfer files between home PCs, not for compiling).