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

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Aug 26, 2019, 19:18 UTC
Message-ID: <20190826191840.GS20404@szeder.dev>
In-Reply-To: <CAAQViEsL+X5ZYmmSjG1JBksGjthHCUyWa3525b8dN7u1XAbvJg@mail.gmail.com>

On Mon, Aug 26, 2019 at 08:42:56PM +0200, Albert Vaca Cintora wrote:

Show 6 quoted lines

> > 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? :)

Those read-only object and pack files contain all the version history, and, therefore, are precious. Making them read-only can protect from accidental deletion.

Show 5 quoted lines

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

None of those files are actually immutable: the next update will overwrite the binaries, libs, and assets, stopping the daemon will remove the pidfile.

OTOH, Git's object and pack files are indeed immutable.