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

From: Albert Vaca Cintora <albertvaka@gmail.com>
Date: Aug 26, 2019, 18:42 UTC
Message-ID: <CAAQViEsL+X5ZYmmSjG1JBksGjthHCUyWa3525b8dN7u1XAbvJg@mail.gmail.com>
In-Reply-To: <xmqq5zmkkn4a.fsf@gitster-ct.c.googlers.com>

On Mon, Aug 26, 2019 at 4:38 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

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