On Mon, Aug 26, 2019 at 4:38 PM Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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
