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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 30, 2019, 16:38 UTC
Message-ID: <xmqqd0gmzk0c.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAAQViEv1wWGTzQ29t0qi9rYoRY=Y86GL7E5rR4XySOBoeRx2pg@mail.gmail.com>

Albert Vaca Cintora <albertvaka@gmail.com> writes:

Show 5 quoted lines

> On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Ah, your "rm" command needs to learn "-f" option, too, then?
>
> The whole point of this thread was to remove the need of -f forcing the removal.

OK, I misunderstood what you wanted to do.

If an implementation of Git were making everything under .git/ read-only, including directories, then it is veriy much reasonable to complain against such an implementation. The usual "I know I am doing something unusual and forcing it" safety given by "rm -rf" is not enough to remove such a clone, and user would need "chmod -R u+w" beforehand to be able to remove---that is being unreasonably paranoid in the name of protecting against mistakes.

But requiring an additional single "f" when doing "rm -rf .git"? Is that realy too much of a hassle? The option "-f" is to allow people deal with an unusual situation, while preventing everyday use from doing something harmful unintendedly. And removing a cloned repository is an unusual situation that would not happen every day, no?