From: David Chmelik <davidnchmelik@gmail.com>
To: git-l <git@vger.kernel.org>
Subject: Re: 'git clone,' build makes user non-writable files (should be option keep user-writable)
Date: Tue, 9 Aug 2022 04:05:46 -0700 [thread overview]
Message-ID: <b47b88fb-89bd-732c-3aeb-75a474a7fdb5@gmail.com> (raw)
In-Reply-To: <CAPx1GvceFLRL_O5zYW98tPdNV9S_Y=fChJafsq+HGkEYixKsZA@mail.gmail.com>
On 7/22/22 8:54 PM, Chris Torek wrote:
> On Fri, Jul 22, 2022 at 5:29 PM David Chmelik<davidnchmelik@gmail.com>
> wrote:
>> On 7/22/22 10:40 AM, Chris Torek wrote:
>>> 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-unwritable though deletable with several/many confirmations so I
>> usually sudo (recommended against).
> Ah, I thought you were (and I definitely was) talking only about the
> *build products*. The stuff inside `.git` itself: some of that, Git
> does set
> to unwritable.
Initially wasn't; don't know why took three replies to clear up
(initially clearly specified non-root usage which others ignored and
mentioned/focused unrelated root topic).
> There is no need to use `sudo` though: a simple
> "rm -rf .git" will blow away the Git repository itself. However:
Starts with 'rm -rf .' which is bad and worse is one key away from 'rm
-rf /': anyone who accidentally pressed <ENTER> after either what I put
in quotation marks (I did both as root on my personal files and entire
PC in 1990s... have you ever? It was normal to use root account then
rather than non-UNIX-like OS that lock it) wants to never again so
typically uses alias which done with sudo (still considered worst last
resort) still has fewer confirmations (one rather than every single
user-unwritable file). I can't believe I'm asking to encourage avoid 'rm
-rf', on mailing list of a tool on UNIX/GNU/Linux (POSIX-based)
operating systems, original which people started avoiding 'rm -rf' in
1970s, but now people say just do it!
>> I'd rather opt-out of .git* subdirectories for every clone.
> In that case, *don't run `git clone in the first place*. The purpose of
> `git clone` is to get you the entire repository. If you want a single
> working
> tree, use `git archive` to make an archive from the commit you want,
> and extract that archive to get the tree you want, without getting all
> the *other* revisions.
Seems much more complicated (and less-documented) and most popular git
sites (though #1 isn't Free/Libre/Opensource Software (FLS, OSS, FOSS,
FLOSS) so rightly condemned) disallow archive. Though I my shell alias
rewrites 'git clone' to then 'chmod u+w .git*' or alternatively 'find .
-iname .git* -perm u-w -exec chmod u+w {} \+' and usually before
archiving, 'sudo rm -rf .git*', aliases are sometimes unavailable and
now a few projects won't compile without such directories. I know you
can't control popular sites' mistakes (nor projects never doing
normally-numbered releases) and they should be irrelevant: unfortunately
most projects use most popular/broken sites, sadly including core
component projects for some/most/all POSIX-based OSs, so couldn't syntax
be easier/detailed so testers can opt-out user-unwritables (for
thousands/millions major cases archive disallowed)?
Apparently many/all version control systems (VCS) make such
(initially) user-unwritables so may consider this request odd but for
tester-only people, it's not odd to dislike such we don't use (unless
ever changes... I've used VCS last 11+ years (likely since late 1990s
or early '0s) and don't plan to use .git* & etc. decades into
foreseeable future but in very-slight chance I do presumably such
files/directories would be useful... for now I've spent hours/days over
decades in frustration: 11+ years ago when projects had a minor bug said
'try from VCS (nightly)' I was glad but led to nightly/critical bugs and
user-unwritables... VCS are a godsend for decreasing years update waits
but (as with most science/technology) have advantages & disadvantages...)
--D
next prev parent reply other threads:[~2022-08-09 11:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 10:35 'git clone,' build makes user non-writable files (should be option keep user-writable) David Chmelik
2022-07-17 11:21 ` Beat Bolli
[not found] ` <YtPtQ6qsIviyTBF2@zbox.drbeat.li>
2022-07-22 13:23 ` David Chmelik
[not found] ` <CAPx1Gvc6ci1CjhL-zjwqkR=4o2yQTrT0V_Hb9bUBNuaBn47M8A@mail.gmail.com>
2022-07-23 0:25 ` David Chmelik
2022-07-23 3:54 ` Chris Torek
2022-08-02 14:34 ` David Chmelik
2022-08-09 11:05 ` David Chmelik [this message]
2022-07-23 4:11 ` Đoàn Trần Công Danh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b47b88fb-89bd-732c-3aeb-75a474a7fdb5@gmail.com \
--to=davidnchmelik@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).