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

[Chris Torek <chris.torek@gmail.com>]

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