On Mon, Aug 26, 2019 at 08:42:56PM +0200, Albert Vaca Cintora 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? :) 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. > 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.
