Re: [Feature Request] Option to make .git not read-only in cloned repos

[Albert Vaca Cintora <albertvaka@gmail.com>]

On Mon, Aug 26, 2019 at 4:38 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> And directories (e.g. .git/objects/) are not made read-only for
> obvious reasons.  Read-only files inside a writeable directory can
> be deleted just like read-write ones can be (iow, the "delete
> permission" comes from the "write permission" of the containing
> directory) so "rm -r .git" should "work" just fine (depending on the
> definition of working, of course---it is discouraged to throw away
> your work).
>

It "works" for some definition of work, but it asks for confirmation
for every file, which is a pain. I'm on Linux.

On Mon, Aug 26, 2019 at 4:27 PM Randall S. Becker
<rsbecker@nexbridge.com> wrote:
>
> Why don't you wrap your clone in a script that calls chmod -R u+w .git after the clone? This seems like a pretty trivial approach regardless of your workflow. This works in Linux, Mac, Windows (under cygwin-bash) and anything else POSIX-ish.
>

Wrapping `git clone` should work as a workaround. Although if that
doesn't break anything... then why were those files read-only in the
first place? :)

The fact that, from a formal point of view, those files are immutable
doesn't seem to justify them being read-only (or, at least, doesn't
follow any convention): there are plenty of immutable files on any
system (eg: all binaries and libs, application assets like images and
icons, pid/lock files for daemons, etc.) that are not made read-only.

I can go with the workaround, but I'm still inclined to think this
option should be built in into git.

Albert