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).
