Hi Joakim, On 2015-09-22 22:58, Joakim Tjernlund wrote: > On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote: >> >> 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) The partial write access idea is definitely not part of the original idea of Git, and your use case is actually the first I heard of. The original idea was really that you either own your repository, or you do not. And that includes the repositories that can be accessed publicly: you own them or you don't. Now, I know that in particular in some corporate setups, there needs to be a permission system in place that disallows certain users from doing certain things (such as editing the config). The Git solution is to set up a server, usually with SSH, and allow users to push and fetch from the repositories, but nothing else (i.e. no shell access), then set up hooks to implement the permission system. This is much less error prone than partially locking down a repository on some network drive because the file system structure simply does not reflect the permission structure. That is where all your troubles come from. >> 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. But then it is your duty to tell *Git* what it can and what it cannot do. Typically via those hooks I mentioned. > 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. No, it would actually make it harder. I seem to recall that there was some problem with renaming a file unless it was already in the same directory as the destination. If all files were to be written to .git/tmp/ first... >> 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. Sure, I understand what you ask for. It's just that Git worked in a different direction for 10 years now ;-) Ciao, Johannes -- 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