* [Feature Request] Option to make .git not read-only in cloned repos @ 2019-08-23 20:43 Albert Vaca Cintora 2019-08-25 11:59 ` Kevin Daudt 2019-08-25 17:54 ` Johannes Sixt 0 siblings, 2 replies; 18+ messages in thread From: Albert Vaca Cintora @ 2019-08-23 20:43 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-23 20:43 [Feature Request] Option to make .git not read-only in cloned repos Albert Vaca Cintora @ 2019-08-25 11:59 ` Kevin Daudt 2019-08-25 14:39 ` Albert Vaca Cintora 2019-08-25 17:54 ` Johannes Sixt 1 sibling, 1 reply; 18+ messages in thread From: Kevin Daudt @ 2019-08-25 11:59 UTC (permalink / raw) To: Albert Vaca Cintora; +Cc: git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-25 11:59 ` Kevin Daudt @ 2019-08-25 14:39 ` Albert Vaca Cintora 0 siblings, 0 replies; 18+ messages in thread From: Albert Vaca Cintora @ 2019-08-25 14:39 UTC (permalink / raw) To: Kevin Daudt, Albert Vaca Cintora, git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-23 20:43 [Feature Request] Option to make .git not read-only in cloned repos Albert Vaca Cintora 2019-08-25 11:59 ` Kevin Daudt @ 2019-08-25 17:54 ` Johannes Sixt 2019-08-25 19:58 ` Albert Vaca Cintora 1 sibling, 1 reply; 18+ messages in thread From: Johannes Sixt @ 2019-08-25 17:54 UTC (permalink / raw) To: Albert Vaca Cintora; +Cc: git 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-25 17:54 ` Johannes Sixt @ 2019-08-25 19:58 ` Albert Vaca Cintora 2019-08-25 22:41 ` Philip Oakley 2019-08-26 14:27 ` Randall S. Becker 0 siblings, 2 replies; 18+ messages in thread From: Albert Vaca Cintora @ 2019-08-25 19:58 UTC (permalink / raw) To: Johannes Sixt; +Cc: git 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-25 19:58 ` Albert Vaca Cintora @ 2019-08-25 22:41 ` Philip Oakley 2019-08-26 14:38 ` Junio C Hamano 2019-08-26 14:27 ` Randall S. Becker 1 sibling, 1 reply; 18+ messages in thread From: Philip Oakley @ 2019-08-25 22:41 UTC (permalink / raw) To: Albert Vaca Cintora, Johannes Sixt; +Cc: git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-25 22:41 ` Philip Oakley @ 2019-08-26 14:38 ` Junio C Hamano 2019-08-26 18:42 ` Albert Vaca Cintora 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2019-08-26 14:38 UTC (permalink / raw) To: Philip Oakley; +Cc: Albert Vaca Cintora, Johannes Sixt, git 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()? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-26 14:38 ` Junio C Hamano @ 2019-08-26 18:42 ` Albert Vaca Cintora 2019-08-26 19:18 ` SZEDER Gábor 2019-08-27 19:35 ` Junio C Hamano 0 siblings, 2 replies; 18+ messages in thread From: Albert Vaca Cintora @ 2019-08-26 18:42 UTC (permalink / raw) To: Junio C Hamano; +Cc: Philip Oakley, Johannes Sixt, git 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-26 18:42 ` Albert Vaca Cintora @ 2019-08-26 19:18 ` SZEDER Gábor 2019-08-27 19:35 ` Junio C Hamano 1 sibling, 0 replies; 18+ messages in thread From: SZEDER Gábor @ 2019-08-26 19:18 UTC (permalink / raw) To: Albert Vaca Cintora; +Cc: Junio C Hamano, Philip Oakley, Johannes Sixt, git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-26 18:42 ` Albert Vaca Cintora 2019-08-26 19:18 ` SZEDER Gábor @ 2019-08-27 19:35 ` Junio C Hamano 2019-08-30 12:49 ` Albert Vaca Cintora 1 sibling, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2019-08-27 19:35 UTC (permalink / raw) To: Albert Vaca Cintora; +Cc: Philip Oakley, Johannes Sixt, git 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-27 19:35 ` Junio C Hamano @ 2019-08-30 12:49 ` Albert Vaca Cintora 2019-08-30 16:38 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Albert Vaca Cintora @ 2019-08-30 12:49 UTC (permalink / raw) To: Junio C Hamano; +Cc: Philip Oakley, Johannes Sixt, git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-30 12:49 ` Albert Vaca Cintora @ 2019-08-30 16:38 ` Junio C Hamano 2019-08-30 18:26 ` Michal Suchánek 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2019-08-30 16:38 UTC (permalink / raw) To: Albert Vaca Cintora; +Cc: Philip Oakley, Johannes Sixt, git 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-30 16:38 ` Junio C Hamano @ 2019-08-30 18:26 ` Michal Suchánek 2019-08-30 19:25 ` Junio C Hamano 0 siblings, 1 reply; 18+ messages in thread From: Michal Suchánek @ 2019-08-30 18:26 UTC (permalink / raw) To: Junio C Hamano; +Cc: Albert Vaca Cintora, Philip Oakley, Johannes Sixt, git 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-30 18:26 ` Michal Suchánek @ 2019-08-30 19:25 ` Junio C Hamano 2019-08-31 20:40 ` Albert Vaca Cintora 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2019-08-30 19:25 UTC (permalink / raw) To: Michal Suchánek Cc: Albert Vaca Cintora, Philip Oakley, Johannes Sixt, git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-30 19:25 ` Junio C Hamano @ 2019-08-31 20:40 ` Albert Vaca Cintora 0 siblings, 0 replies; 18+ messages in thread From: Albert Vaca Cintora @ 2019-08-31 20:40 UTC (permalink / raw) To: Junio C Hamano; +Cc: Michal Suchánek, Philip Oakley, Johannes Sixt, git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-25 19:58 ` Albert Vaca Cintora 2019-08-25 22:41 ` Philip Oakley @ 2019-08-26 14:27 ` Randall S. Becker 2019-08-26 15:27 ` Junio C Hamano 1 sibling, 1 reply; 18+ messages in thread From: Randall S. Becker @ 2019-08-26 14:27 UTC (permalink / raw) To: 'Albert Vaca Cintora', 'Johannes Sixt'; +Cc: git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-26 14:27 ` Randall S. Becker @ 2019-08-26 15:27 ` Junio C Hamano 2019-08-26 16:19 ` Randall S. Becker 0 siblings, 1 reply; 18+ messages in thread From: Junio C Hamano @ 2019-08-26 15:27 UTC (permalink / raw) To: Randall S. Becker Cc: 'Albert Vaca Cintora', 'Johannes Sixt', git "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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [Feature Request] Option to make .git not read-only in cloned repos 2019-08-26 15:27 ` Junio C Hamano @ 2019-08-26 16:19 ` Randall S. Becker 0 siblings, 0 replies; 18+ messages in thread From: Randall S. Becker @ 2019-08-26 16:19 UTC (permalink / raw) To: 'Junio C Hamano' Cc: 'Albert Vaca Cintora', 'Johannes Sixt', git 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-08-31 20:42 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-23 20:43 [Feature Request] Option to make .git not read-only in cloned repos Albert Vaca Cintora 2019-08-25 11:59 ` Kevin Daudt 2019-08-25 14:39 ` Albert Vaca Cintora 2019-08-25 17:54 ` Johannes Sixt 2019-08-25 19:58 ` Albert Vaca Cintora 2019-08-25 22:41 ` Philip Oakley 2019-08-26 14:38 ` Junio C Hamano 2019-08-26 18:42 ` Albert Vaca Cintora 2019-08-26 19:18 ` SZEDER Gábor 2019-08-27 19:35 ` Junio C Hamano 2019-08-30 12:49 ` Albert Vaca Cintora 2019-08-30 16:38 ` Junio C Hamano 2019-08-30 18:26 ` Michal Suchánek 2019-08-30 19:25 ` Junio C Hamano 2019-08-31 20:40 ` Albert Vaca Cintora 2019-08-26 14:27 ` Randall S. Becker 2019-08-26 15:27 ` Junio C Hamano 2019-08-26 16:19 ` Randall S. Becker
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.