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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25/08/2019 20:58, Albert Vaca Cintora wrote:
On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt <j6t@xxxxxxxx> wrote:
Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora:
However, I'm sure that a large percentage of developers out there will
agree with me that having to use force (-f) to delete every cloned
repo is annoying, and even worse, it creates the bad habit of always
force-deleting everything.
IMO, the bad habit is to delete cloned repositories all the time. If
your workflow necessitates this, then you are doing something wrong.
Maybe you have an X-Y-problem?

-- Hannes
There are plenty of valid workflows where one would delete a repo.

What you suggest is like saying I shouldn't delete pictures from my
camera, because in that case I shouldn't have taken them in the first
place.

Sometimes I clone a repo just to grep for an error string and then I
don't need it anymore, or I clone several repos until I find the one
that contains what I want and delete the rest. Sometimes I want to
write a patch for some software I don't develop regularly so I don't
need to keep a clone of it.

In any case, it would be useful to know the reason those files are
read-only in the first place. Do you guys know who might know?

Albert
Surely (?), if we are considering our stored revisions to be immutable, then removing the write bit is the right thing to do. If I understand correctly (*) we don't separate the delete permission from 'no-write' permissions, so the consequence will be that such files are read-only.

Philip

(*) I'm primarily a Windows user, so certain Linux nuances pass me by ;-). I simply delete the repo folder then click the gui dialog to agree to delete the r/o files. Simples.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux