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

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

[Albert Vaca Cintora]

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

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

[Kevin Daudt]

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.

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

[Albert Vaca Cintora]

On Sun, Aug 25, 2019 at 1:59 PM Kevin Daudt <me@ikke.info> wrote:
>
> 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.

Indeed, not all files in .git are read-only. I'm talking about those which are.

On Sun, Aug 25, 2019 at 1:59 PM Kevin Daudt <me@ikke.info> wrote:
>
> 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.

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

[Johannes Sixt]

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

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

[Albert Vaca Cintora]

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

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

[Philip Oakley]

On 25/08/2019 20:58, Albert Vaca Cintora wrote:
> 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.

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.

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

[Junio C Hamano]

Philip Oakley <philipoakley@iee.email> writes:

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

Perhaps Windows filesystem or file manager application behave
differently and tries to protect users from removing read-only files
in read-write folders by mistake, or something?  If that is what the
thread is complaining about, I agree that's a bit unfortunate.
Perhaps Windows port can implement "this is an immultable file---do
not write into it" slightly differently in adjust_shared_perm()?

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

[Albert Vaca Cintora]

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

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

[SZEDER Gábor]

On Mon, Aug 26, 2019 at 08:42:56PM +0200, Albert Vaca Cintora 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? :)

Those read-only object and pack files contain all the version history,
and, therefore, are precious.  Making them read-only can protect
from accidental deletion.

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

None of those files are actually immutable: the next update will
overwrite the binaries, libs, and assets, stopping the daemon will
remove the pidfile.

OTOH, Git's object and pack files are indeed immutable.

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

[Junio C Hamano]

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

> It "works" for some definition of work, but it asks for confirmation
> for every file, which is a pain. I'm on Linux.

Ah, your "rm" command needs to learn "-f" option, too, then?

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

[Albert Vaca Cintora]

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.

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

[Junio C Hamano]

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?

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

[Michal Suchánek]

On Fri, 30 Aug 2019 09:38:11 -0700
Junio C Hamano <gitster@pobox.com> wrote:

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

Not everyone's day. Some people's day, sure.

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.

That's why this request makes sense to me.

Thanks

Michal

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

[Junio C Hamano]

Michal Suchánek <msuchanek@suse.de> writes:

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

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

[Albert Vaca Cintora]

On Fri, Aug 30, 2019 at 9:25 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

I would permanently enable --no-read-only-file-in-git for all newly
cloned repositories (via an alias, or .gitconfig if possible), so
there would be no need to type it every time.

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

[Randall S. Becker]

On August 25, 2019 3:59 PM, Albert Vaca Cintora wrote:
> 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?

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.

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

[Junio C Hamano]

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

But on anything POSIX-ish, is it a problem for some files (but not
any directory) in .git is made read-only?

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

[Randall S. Becker]

On August 26, 2019 11:28 AM, Junio C Hamano wrote:
> "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
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.
> 
> But on anything POSIX-ish, is it a problem for some files (but not any
> directory) in .git is made read-only?

Not for me or anyone I personally support. As I suggested to Albert,
wrapping a clone in a script with a chmod would solve the problem with
minimal work.

My own personal issue is convincing people not to clone for every topic
branch, but that's unrelated.