On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote: > Hi Joakim, > > On 2015-09-21 19:08, Joakim Tjernlund wrote: > > On Mon, 2015-09-21 at 09:48 -0700, Junio C Hamano wrote: > > > Duy Nguyen <pclouds@xxxxxxxxx> writes: > > > > > > > Is it really necessary to remove write access in $GIT_DIR? Do we (git > > > > devs) have some guidelines about things in $GIT_DIR? > > > > > > Those who are allowed to "git push" into it should be able to write > > > there. It is a different matter that "git" program itself may make > > > a policy decision to disallow some operations that the filesystem > > > bits alone would have allowed (e.g. you can arrange the "pusher" to > > > only come over the wire via "receive-pack" and "receive-pack" may > > > deliberately lack support for writing into $GIT_DIR/config). > > > > > > > I view $GIT_DIR similar to "/" and "/tmp". Normally one does not let > > normal users write to "/" > > as you want to keep this level clean. It is not obvious to everybody > > what files are important > > under $GIT_DIR when mixed with tmp files etc. > > $GIT_DIR/tmp would solve this nicely. > > By now it is pretty clear that you won't find many people here you share your opinion about locking down the > Git directory. So I note. > > The reason should be easy to understand: Git's concept is based on the idea that you have full control over > your repository. Other repositories you might only have read access. Yes and some repos I only have partial write access to(config, hooks etc. might be readonly) > > But this idea you have, to somehow introduce fine-grained levels of control, this idea would imply that all > of a sudden Git is no longer free to write to its files as it likes. And as far as Git is concerned, > everything inside .git/ *are* its files. This does not compute for me, files inside git are git's files, I only think that not all users to a repo should have the same (write) access. In this case it mostly to protect the repo from "creative" users and accidents. > > So in essence, the core concept of Git -- you clone a repository you cannot write to so that you have a > local repository you can do *anything you like* to -- is pretty much incompatible with this idea of a > selective lock down of files in .git/ that not only would require you to know very exactly what files Git > might want to write, but also to keep yourself up-to-date with Git's development as to which files it might Don't see how I can avoid some of that if you want to protect areas of the repo from accidents etc. > want to write for *every* new version. Making only .git/tmp/ a writable location further fails to > acknowledge the fact that the hierarchy of to-be-written files follows the function of those files, not any Curious, how would you set up some level of protection on a repo? A .git/tmp/ would make housekeeping easier, you would know that every file under .git should be there and if you find something you don't recognize you would react. > write permission hierarchy. Since the idea seems so alien to Git's core concept, I called it "overzealous". > If that hurt your feelings, I am sorry and would like to apologize. No feelings hurt, I too regret my choise of words. > Having said all that, I believe that reiterating this idea without pointing to any benefit will continue to > fail to convince people that the idea is sound and that Git's core concept should change. If you need to > exert more control in a specific repository, you simply make it accessible only as a non-file-system remote > (where only `git`, `git-receive-pack` and `git-upload-pack` are allowed to be executed) and define hooks > that can accept or deny on a *much* finer level than file system permissions ever could, after all. Even if I did go through this hassle, I would prefer if temporary data were put somewhere else than .git/ as I think mixing config/persistent data with temporary data in the same directory is something that should be avoided. Anyhow, I see that this idea is not something upstream agrees on so I will back off now. Jocke-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html