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

> Hi git folks,
> 
> Honestly I'm not aware of the reason behind .git being read-only, but
> I'm sure there is one.
> 
> 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.
> 
> Would you find reasonable to add an option to keep .git writable on
> cloned repos?
> 
> PS: I'm not subscribed to the list, so please CC me on replies.
> 
> Thanks!
> Albert

>
> On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote:
> > Hi git folks,
> >
> > Honestly I'm not aware of the reason behind .git being read-only, but
> > I'm sure there is one.
> >
> > 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.
> >
> > Would you find reasonable to add an option to keep .git writable on
> > cloned repos?
> >
> > PS: I'm not subscribed to the list, so please CC me on replies.
> >
> > Thanks!
> > Albert
>
> To clarify, you are probably referring to things like pack-files, which
> are created read-only. Most files / directories in .git are writable.
>
> It think this is already quite old behavior and I could not find any
> reference as to why this is done.

>
> On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote:
> > Hi git folks,
> >
> > Honestly I'm not aware of the reason behind .git being read-only, but
> > I'm sure there is one.
> >
> > 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.
> >
> > Would you find reasonable to add an option to keep .git writable on
> > cloned repos?
> >
> > PS: I'm not subscribed to the list, so please CC me on replies.
> >
> > Thanks!
> > Albert
>
> To clarify, you are probably referring to things like pack-files, which
> are created read-only. Most files / directories in .git are writable.
>
> It think this is already quite old behavior and I could not find any
> reference as to why this is done.

>
> 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

> On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt <j6t@kdbg.org> 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.

>
> 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).
>

> > 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.

> 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.

> Albert Vaca Cintora <albertvaka@gmail.com> writes:
> 
> > 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?

>> 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?
> ...
> I am not in this situation so often but indeed I sometimes clone
> several repositories in a day to search for a patch or piece of code
> and then don't need them anymore. Some people may be in such situation
> more often or regularly.

>
> But between these two:
>
>         $ git clone --no-read-only-file-in-git https://github.com/foo/bar
>         ...sightsee...
>         $ rm -r bar
>
> to avoid "f" in "rm -r", vs.
>
>         $ git clone https://github.com/foo/bar
>         ...sightsee...
>         $ rm -rf bar
>
> to clone a repository you only have a tentive interest in just like
> any other more permanent repositories, I am not sure how the former
> is preferrable.

> To: Johannes Sixt <j6t@kdbg.org>
> On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt <j6t@kdbg.org> 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?

>> 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?
>
> 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.

> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> >> 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

> 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?
> >
> > 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.
> 
> But on anything POSIX-ish, is it a problem for some files (but not any
> directory) in .git is made read-only?