Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)

[David Chmelik <dchmelik@gmail.com>]

On 7/17/22 4:06 AM, Beat Bolli wrote:
> On Fri, Jul 15, 2022 at 03:35:49AM -0700, David Chmelik wrote:
>> What did you do before the bug happened?
>> 'git clone,' built various software (with gcc, BSD & GNU make, autotools,
>> cmake, etc.)
>>
>> What did you expect to happen?
>> Option: keep cloned/built/etc. files user-writable.
>>
>> What happened instead?
>> Needed chmod or 'sudo rm -rf.'
>>
>> What's different between what you expected and what actually happened?
>> Option: keep cloned/built/etc. files user-writable, otherwise (has been said
>> 15+ years) encourages 'sudo rm -rf.'
>>
>> Anything else you want to add:
>>          I try/test/debug (and report bugs) many software commits but don't
>> commit so need cloned/built/etc. files writable as user & even system-wide
>> options: who hasn't made 'rm -rf' mistakes? (unrelated but someone might
>> claim is: I don't use non-UNIX-like OS that shell alias 'rm -rf' to confirm
>> every file (potentially thousands) and though made my own alias (confirm
>> once) it's longer, sometimes unavailable so don't always use (many people
>> don't)... software should always have user-writable files option.)  Below
>> indicates GNU/Linux but also have often used git on *BSD/Unix.  I'm not on
>> git mailing list but you can CC me all replies.
> When building software as the current user, the build artefacts are
> owned by this user.
Ownership, permissions are different: one can own files yet have zero 
permission to write/delete and be denied that.  After cloning, 
archiving, building most/all projects I tried from (hundreds/thousands) 
git commits I typically/always had zero permission to write/delete some 
files/directories within--despite owning--which led to more steps to 
delete and temptation to sudo 'rm -rf' (or preferably alias or script 
such as 'rm -RfI' (FreeBSD UNIX) or 'rm -rf --interactive=once' (GNU) 
but may not always be available).

> Are you building the software using Docker containers that run as root?
I don't use containers.  I noticed some projects' cmake & 'sudo make 
install' put root-owned files in build directory but doesn't seem to 
happen with other build systems--especially not plain make (BSD nor GNU 
nor with autotools)--still-used by almost all projects I try commits from.
         So, I don't think root is the problem; IIRC usually problem was 
cloned directories had one or more subdirectories (such as .git* or 
files/subdirectories further in those) that were/became user 
non-writeable so I ended up writing a bash function (on SlackWiki.com & 
docs.Slackware.com) to make git clones user-writable: should be by 
default (before & after building in .git*, etc.) and/or a 
well-documented beginner/easy option (is it even an option?) because 
surely many more people only test than commit.  Instructions say 'git 
clone URL' assuming someone will commit rather than only test and want 
to avoid user-non-writeable files (I doubt I even need .git* 
subdirectories until ever start committing (don't plan to: I only like 
decimal-numbered tarballs made manually rather than version control) so 
would rather opt-out).  I don't recall commits from three other/older 
major version control systems be(com)ing user non-writeable (though all 
less-used apart from on classic UNIX/*BSD I don't use much anymore 
besides servers but wish had more hardware support to be more 
desktop-useable).