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

From: Chris Torek <chris.torek@gmail.com>
Date: Jul 23, 2022, 03:54 UTC
Message-ID: <CAPx1GvceFLRL_O5zYW98tPdNV9S_Y=fChJafsq+HGkEYixKsZA@mail.gmail.com>
In-Reply-To: <ccbc1e81-b406-9e73-7aa5-956ffae7074b@gmail.com>

On Fri, Jul 22, 2022 at 5:29 PM David Chmelik <davidnchmelik@gmail.com> wrote:

Show 9 quoted lines

> 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-non-writable 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 non-writable. There is no need to use `sudo` though: a simple "rm -rf .git" will blow away the Git repository itself. However:

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

Chris