`.git/objects/` directory contents: make git set the write permission instead of 'read-only'

Question

My problem is that git repos, unlike any other directory, won't be deleted with rm -r -- you need to specify rm -rf. This is because all the files in the .git/objects directory have read-only permissions. My question is:

What setting must I set, or what source file must I perform surgery on, to make git store its files .git/objects/... with permissions/umask 644 instead of 444 permissions, a.k.a. read-write for the user, read-only for group and others? It need not change existing object files, as long as all object files from hereonout are writable.

---

(The two sections below this line are not part of the question: just dead-ends I have investigated, and a pre-emptive response to the ‘you shouldn't want that’-instinct. Feel free to skip.)

---

Resources I have tried

• Assiduous web-searching -- no luck
• git help config -- setting tar.umask = user looked promising, but the problem persisted.
• The SO question Git Directory Permissions Always 000 and its link to umasks in the index format -- these are about the index, not about the objects dir. Also, no mention of how to change umasks of object files.

‘That's not what you want’

I realize answers like ‘you shouldn't want that’ / ‘that's intentional' / 'don't do that then’ / ‘just remember to use rm -rf for git repositories’ are tempting, here, but they're not what I'm looking for. Some preemptive responses:

• ‘object files are intentionally read-only because the user shouldn't edit them’: Making them read-only is overkill: it prevents editing and deletion, even though deleting a git repo is a common and legitimate desire. The 'don’t accidentally edit' nature of object files is made plenty obvious in other ways: they live under .git/objects/; they have hash-based names; and they have binary contents.
• If, after reading the previous point, you are still afraid of accidental edits: the experiment has been tried, and is a success. Mercurial repositories have a .hg/store/ that is writable. I have never heard of anybody (myself included) accidentally editing it; and plain rm -r my_hg_repo works without surprises.

Answer 1

My answer below isn't so much a solution for your problem, just more explicit information about why and where the git maintainers made this choice.

See: Why is git creating read-only (444) files? That stack overflow question references the relevant source code and documentation.

I couldn't find any relevant setting(s).

This git behavior causes an issue for me with a personal, local, offline, bare git repo. I need everything in the .git dir to be user-writable because I use a custom bitrot detector, and that bitrot detector works by writing a checksum to extended file attributes for later verification. Sure would be nice if there were a git configuration option around this, but I'm guessing writable index files is an edge case and the git maintainers might not even accept a patch to add one. Or they might.

---

I'm sure you're past all the rest below, but I'll include it for completeness and for anyone else who wants these git internal files to have more open permissions.

I imagine the git maintainers use 0444 perms for these files and I basically agree with their decision, so I use a fairly brute-force workaround. Before I run my bitrot detector, I give myself write permission:

find .git/objects/ -perm /u+w | xargs -r chmod u+w

and I remove it afterwards with:

find .git/objects/ -perm /u+w | xargs -r chmod u-w

Since git is "special" with its read-only files, maybe alias gitnuke (or make it a function) to rm -rf or do a find workaround like I did above. Side note: I usually use rm -rf to recursively delete any directory tree anyway, so I've never run into the problem you face.